Re: How to eliminate redundant constant move instructions

amker <can.finner@gmail.com>
Tue, 1 Nov 2011 19:21:54 -0700 (PDT)

          From comp.compilers

Related articles
How to eliminate redundant constant move instructions amker.cheng@gmail.com (Amker.Cheng) (2011-10-31)
Re: How to eliminate redundant constant move instructions kaz@kylheku.com (Kaz Kylheku) (2011-10-31)
Re: How to eliminate redundant constant move instructions gneuner2@comcast.net (George Neuner) (2011-11-01)
Re: How to eliminate redundant constant move instructions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-11-01)
Re: How to eliminate redundant constant move instructions can.finner@gmail.com (amker) (2011-11-01)
Re: How to eliminate redundant constant move instructions can.finner@gmail.com (amker) (2011-11-01)
Re: How to eliminate redundant constant move instructions can.finner@gmail.com (amker) (2011-11-01)
Re: How to eliminate redundant constant move instructions amker.cheng@gmail.com (amker) (2011-11-01)
Re: How to eliminate redundant constant move instructions amker.cheng@gmail.com (amker) (2011-11-01)
Re: How to eliminate redundant constant move instructions gneuner2@comcast.net (George Neuner) (2011-11-02)
Re: How to eliminate redundant constant move instructions acolvin@efunct.com (mac) (2011-11-03)
Re: How to eliminate redundant constant move instructions kaz@kylheku.com (Kaz Kylheku) (2011-11-03)
Re: How to eliminate redundant constant move instructions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-11-03)
[6 later articles]
| List of all articles for this month |

From: amker <can.finner@gmail.com>
Newsgroups: comp.compilers
Date: Tue, 1 Nov 2011 19:21:54 -0700 (PDT)
Organization: Compilers Central
References: 11-10-019 11-11-004
Keywords: optimize
Posted-Date: 02 Nov 2011 22:40:25 EDT

On Nov 2, 2:32 am, George Neuner <gneun...@comcast.net> wrote:
> On Mon, 31 Oct 2011 17:53:46 +0800, "Amker.Cheng" <amker.ch...@gmail.com> wrote:
> >I found following intermediate codes are generated in gcc
>
> >rx <- 0
> >...
> >use rx
> >...
> >ry <- 0
> >use ry
> >...
>
> >It's normally a result of const propagation.
> >After register allocation, It is likely rx/ry get allocated into
> >different hard registers.
> >Thus in final codes, there would be a redundant "move 0" instruction.
>
> >The story even stands for Os compiling, so the question is:
> >Is there any optimization technique dedicates to this kind of case?
> >Or is it normally handled by other optimizations as sub task?
>
> It's very hard to tell anything without more context - we need to know
> what CPU, what compiler, and we need to see the surrounding code.
>
> Because you mention "Os" I'm assuming you are using GCC. Incidentally,
> that really should be written as "-Os" so people understand you mean
> an option rather than thinking you're compiling an operation system


Sorry for the misleading term, the test case showed at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
which is actually a reported gcc bug.


> GCC doesn't really perform a separate constant propagation
> optimization ... instead it generically tracks use of values to (try
> to) minimize redundant loads. There is a separate optimization,
> -fcprop-register, which is a peephole pass that eliminates redundant
> register moves (introduced by other optimizations), but that is
> performed after register allocation.


Yes, I have noticed this pass. Seems it can solve the problem if I
can:
1, extend the pass in value numbering way, at least for const values.
2, extend the pass in global data analysis way.


> You might be asking "if the value already is in a register, why not
> just use it rather than load a second register?" The answer to that
> likely is a scheduling issue which depends on the use of the first
> register. You have to remember that many CPUs can execute multiple
> instructions in parallel, and those parallel instruction streams may
> be executed out of order with respect to a program listing.
>
> On most CPUs loading an immediate constant is as cheap as a register
> move. Also, loading a constant ties up only the target register
> whereas a move ties up both target and source registers.


Yes, This is the point I missed. So even the codes are optimized into:
rx <- 0
...
use rx
...
use rx


It might be worse than original codes considering out-of-order and
parallel execution.
In this way, how should I know for sure which case is better?


> So a lot more information is needed to say whether the compiler is
> doing something dumb or doing something clever.


Thanks.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.