Re: SSA for Trees - PRE implementation

[Daniel Berlin <dberlin at dberlin dot org>]

On Jan 8, 2004, at 10:35 PM, Sidney Page Bennett wrote:

> On Thu, 2004-01-08 at 14:47, Daniel Berlin wrote:
> > >  I guess the real question is ... Do
> > > you see it eventually replacing the either existing PRE pass?
> > Not unless we don't produce any partially redundant expressions in the
> > backend.
>
> I assumed that the new SSA PRE would supplant the existing PRE passes.
> > From your reply, i gather that, instead, it will be in addition to the
> existing passes.  I understand why.
>
> However, it seems that the new SSA PRE would be somewhat redundant as
> most of the evaluations it removes would be removed by lazy code motion
> or Morel-Renvoise PRE.

Neither of which we can or want to perform on our SSA intermediate form 
without significant work, or going into and out of SSA form.

There is one other algorithm that currently exists (which was written 
about well after i started implementation) that does the same as PRE as 
well, in a simpler form.  It is not easily amenable to straight line 
strength reduction, however.

> In my work, the SSA implementation was no more
> powerful than LCM, just more difficult to implement.

Uh, the basic SSAPRE algorithm is simply a formulation of LCM for SSA, 
why would you think it would be more powerful without doing the things 
that made it more than a normal PRE algorithm, which were load motion 
(including speculation), and integrated strength reduction (both of 
which are a pain in the ass to integrate *into* PRE. They are usually 
done as a separate post-pass).
>   Are you finding
> that the additional SSA PRE is worthwhile?
It's worth a few % on SPEC, last I checked.