Re: [patch] Lno branch merge part 3 -- ssa form updating improvements

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > yes, although it would be relatively easy to avoid (the reason I did not
> > do it is that you would need to somehow tell which of the definitions is
> > "primary" one, which sometimes does not make much sense).
> > 
> Ah, see, this is a problem.  We need to never invalidate SSA information
> for *any* variable.  Today, we have alias information.  In a few days we
> will have value numbers, ranges, type information, etc.  In fact, after
> jump threading is fixed to stay in SSA form, we will make it impossible
> to call rewrite_into_ssa() more than once.

but this is no problem with rewrite_ssa_into_ssa.  It just creates
*duplicates* of existing ssa names.  So it can simply copy the
information (in fact it does now for alias information).

You cannot avoid this, with any approach.

> > With the patch, we just copy the header, obtaining
> > 
> > L0:
> >   x_1 = phi (x_0)
> >   if (x_1 > 100)
> >     goto end;
> > 
> > L1:
> >   x_2 = foo (x_1);
> > 
> > start:
> >   x_1 = phi (x_2);
> >   if (x_1 > 100)
> >     goto end;
> >   goto L1;
> > end:;
> > 
> > x_1 now has multiple definitions.  Now the call to rewrite_ssa_into_ssa
> > creates the new versions for it and the neccesary phi node at L1.
> > 
> Sounds like you are just inserting new definitions.  Ken Zadeck provided
> a method for inserting definitions while keeping the SSA form.

Yes; the method is not really much different from what
rewrite_ssa_into_ssa does. The exceptions are that
rewrite_ssa_into_ssa searches for new definitions by scanning all the
statements (making it possibly a bit slower), and that it works for
multiple definitions at a time (making it possibly a bit faster, and
much easier to use then direct incremental algorithm).

Zdenek