To: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: this is optimization? 
Date: Fri, 14 Oct 94 08:30:57 -0400
From: Mike Collison <collison AT sw DOT stratus DOT com>


>    Note that the GNU optimizer is platform independent.  Thus the
> assembler's code translator has to come in different versions for
> Sparc, 386, 68k, MIPS, and Alpha, but the rest of the compiler suite,
> including the optimizer, does not (or not very much).  So what happens
> is that the optimizer mangles a platform-independent intermediate form
> of code (C for the GNU optimizer, proprietary compilers often use
> proprietary codes---this is the only reasonable way to implement
> global optimization without platform dependence), and these get
> translated into platform-dependent stereotyped sequences.  These
> stereotyped sequences often need to protect certain values or make
> them available in stereotyped places on some platforms but not on
> others.  But if what the program is really interested in is some side
> effect of a function, a useless register op will get generated.  (Eg,
> many C functions are declared as returning non-void, either implicitly
> int---bad practice!---or explicitly---as in the string library, but
> callers rarely use the value.  The "optimized code" will often show
> the value being moved into some standard place for return values,
> typically eax.  Casting such a call to void might help the code
> generator, but it might not.)  Since the platform independent
> optimizer doesn't know the peculiarities of each machine, it can't do
> anything about such infelicities.
>    OTOH, a local, AKA peephole, optimizer, looks at the generated
>code in assembler/machine form and eliminates such sequences of ops.
>    Bottom line is the GCC optimizer never sees the generated
> assembler, or it sould be smarter about register thrashing.  I think
> BTW that this kind of thing is less common (or easier to avoid) on
> elegant architectures like the 68k series.  That's why bit-flickers
> like it.
>     --Steve

I stand by my earlier posting. Take a look at GCC's RTL dump output some
time (Dump all the phases using '-da'). Then have a look at the RTL output
after local register allocation (the file with the .lreg) extension. *That*
is what GCC would generated if there register allocation worked optimimally.
I *guarantee* that you will *not* see redundant moves such as the one you
see in Kimbereley's posting. Why? Because earlier optimzations passes (e.g.
data flow optimization) have removed them! These redundant moves are generated
by the reload phase of GCC. It needs to be cleaned up, plain and simple.

Mike