Re: [ast-optimizer-branch]: tree-cfg.c insertion fixes

[Jan Hubicka <jh at suse dot cz>]

> On Tue, 04 Jun 2002, Daniel Berlin wrote:
> 
> > I'm saying that if you simplify inserted statements, you need 
> > to keep track of which bb's/stmt's are created by 
> > simplification (which we don't do now), so that *when* we 
> > start incrementally updating SSA, we can actually do it.
> > Right now, this information is not tracked.
> > 
> Ah, yes.  Now I get it.  That brings me to the next topic.  I've
> been thinking that once a function is simplified, further code
> generation should always generate SIMPLE trees.
> 
> However, I can also see cases where it would be easier to
> generate some arbitrary tree expression and pass it to the
> simplifier to beat it into shape.  In that case, the simplifier
> will have to be aware of the CFG and SSA.
> 
> There's also the eternal debate of whether we try to keep SSA
> incrementally updated or re-compute from scratch.  I'm more
> inclined to try and keep it incrementally up to date, but I've
> had bad experiences with concurrent SSA in the past.

This is something I was thinking about in the past.  For instance I have
the superblock formation/loop unrolling pass that currently need webizer
to be run afterwards to split copied temporary registers into separate
pseudos.

It would make sense to make such transformation on SSA form and update
it incrementally, as that would create new SSA names as needed.  Are
there some algoirithms to do such trick easilly and effectivly?

Honza
> 
> 
> Diego.