Re: -fssa kicks butt on alphaev6 ieee floating point code

[Brad Lucier <lucier at math dot purdue dot edu>]

> From rth@cygnus.com  Thu Mar 16 14:49:01 2000
> On Thu, Mar 16, 2000 at 01:37:52PM -0500, Brad Lucier wrote:
> > > It's an accident.  What it means is that our register allocator
> > > really bites.
> > 
> > The register allocator cannot deal well with the constraint
> > that a source operand cannot overlap a destination operand.
> 
> Yes.  Which exactly proves my point.
> 
> A better register allocator would take these constraints into
> account much earlier.  A slightly smarter register allocator
> that's not quite smart enough will happily undo any changes
> that going toand from SSA form bought you.  Combine will often
> work to thwart you was well.

I don't want to belabor this point too much, but before trying the
-fssa flag, I thought about what the register allocator would need
to do to take these constraints into account earlier, and I thought
that the SSA canonical form was precisely the kind of transformation
the register allocator would need to generate better code.  (I.e.,
the register allocator would have to be pessimizing to undo what SSA
does.) So, to my mind, it was no "accident" that it happened to work
(I'm not randomly trying flags to try to get better code generation).

It is really a shame that the -fssa transformations are buggy now (or else
expose bugs in other parts of the compiler), because it makes one hell of
a difference on some codes.  For example, in a 3-D geometry code I have,
the composition of two 4x4 matrix transformations is compiled to 124
instructions that are scheduled in 70 cycles with -fssa, and compiled
to 223 instructions that are scheduled in 367 cycles without -fssa.
So we're talking a factor of 5 difference.

Brad