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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.