Re: More fun with SSA

[Toshi Morita <tm2 at best dot com>]

> Right now our SSA path sits between cse1 and gcse.  For various reasons
> I think that's wrong and it would be better if we moved the SSA path
> to an earlier point in the compiler.  I have in fact been beating on a couple
> targets in this mode for a few weeks and I've become convinced it's the
> right thing to do.
> 
>   a. It's almost a certainty that for SSA to be useful on RTL that we're
>      going to have to have a more gradual lowering of RTL.  In that model
>      the SSA path would have the higher level optimizers and the old path
>      would consist of the lower level optimizers.
> 
>      Thus, it's kind-of silly to have the high level optimizer sit in the
>      middle of the low level optimizer path.
...

>   d. By moving SSA up in the path with the expectation that it'll work on
>      a higher level RTL, the SSA optimizers themselves become much much
>      simpler.  It would be a shame to have to teach the SSA optimizers how
>      to deal with HAVE_cc0, HIGH/LO_SUM, and all the target dependent stuff
>      that we find in our typical GCC optimizer.

On a related note, could the SSA passes use abstract "stack slots" and
defer assignment of hard stack offsets until RTL is generated?

This would be quite nice for processors with short displacements like
the Hitachi SH, MIPS16, Thumb, and PA-RISC (also IA-64?).

It would allow several things:

1) Allow the placement of frequently used variables/temporaries near the
   stack pointer so they can be accesssed with short displacements,

2) Simplify the elimination of unused stack slots because the offsets
   wouldn't need to be adjusted later,

I'm guessing as more processors move to packed instruction words (VLIW/EPIC)
and embedded processors start pushing code density, this will become
more important...

Toshi