Re: Replace rename_ssa_into_ssa with update_ssa

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

Hello,

thanks for the timings; it's not that I would that much had doubts about
the results (the lcssa for vitual names definitively must be expensive),
just they should be included with this (a bit controversial, IMHO) patch.

> On Sat, Apr 23, 2005 at 03:52:35AM +0200, Zdenek Dvorak wrote:
> > Hello,
> > 
> > > This patch brings over most of the changes in tree-cleanup-branch.  
> > > I think that all that's left is the re-ordering of tree passes.
> > > 
> > > The main change in this patch is the replacement of rewrite_ssa_into_ssa
> > > with update_ssa (the incremental SSA updating mechanism).  As a
> > > side-effect of this change, it is no longer necessary to keep
> > > virtual operands in loop-closed SSA form.  This provides some
> > > nice compile time speedups in the loop passes.
> > 
> > hmm... I wonder whether this is really a good idea.  This means that
> > operations like loop unrolling will leave the ssa form for virtual
> > operands broken, making it impossible to use it until update_ssa is
> > called.
> >
> Well, yes.  But this is true of any other updating scheme, after
> you unroll the loop you have to update the SSA form before you
> can do anything with the code.  I think I'm missing your point.
> Could you show me a test case with broken code?

no; sorry, I misunderstood the code a bit.  Just one question -- would
not it be possible to have update_ssa call directly inside
tree_duplicate_loop_to_header_edge, instead of having the caller of the
function do it?  It seems less error-prone to me.

> > Could you please remove my name from the changelog entry?  I have
> > nothing to do with this patch
> >
> This is an odd request.  Credit where credit's due.  You
> implemented the code to replace calls to rewrite_ssa_into_ssa
> with another scheme.  I kept those hunks from your original
> patch.

Well, but there is not that much of my code left.  It's not question
of credit for me, I just don't want to risk someone asking me about
the code, or even wanting me to fix the possible bugs in a code I do
not understand entirely.

> So, I would try to encourage new passes to try and use update_ssa
> whenever possible and only hand-code the SSA updating when the
> generic updating is slower and can't be easily sped up.

Great, that's one of the things I wanted to hear for quite some time.
I would be even happier to hear this opinion before I was forced to waste
my time by working on the specialized "hand-code" SSA updating
(instead of speeding up and improving the generic SSA form updating as
I wanted to originally), but even this is a progress :-).

Zdenek