Re: [tree-ssa] [RFC] loop versioning

[Jan Hubicka <jh at suse dot cz>]

> Hello,
> 
> > > > What if I rename it to tree_duplicate_head_bb () and implement
> > > > new duplicate_bb() as Jan suggested ?
> > > 
> > > Please avoid creating unnecessary code duplication.  If you need to
> > > extend functionality provided by tree_duplicate_bb in some way, it would
> > > be probably preferable to either extend it, or use it as a subroutine and
> > > just add the extra functionality you need.
> > > 
> > > As for Honza's suggestions, I assume he was speaking about something like
> > > cfglayout.c:copy_bbs.
> > 
> > Yes, that is what I would like to have (I forgot that we have that
> > function already).  If we make tree_duplicate_bb a CFG hook (I will make
> > that patch at evening) it will run right away on SSA.
> > It would be nice if we were able to have companion function to update
> > SSA, but I will have to give it a deeper tought on whether it is
> > possible at all.
> 
> it is unfortunately not straightforward unless you are copying a region
> with just a single exit edge (then you can just rename the defined
> variables, put appropriate phi nodes at this exit, and you are done).
> 
> If there is more than one exit, you end up with insertion of new
> definitions on arbitrary places over the cfg, for which probably the
> only solution is to run the ordinary ssa construction algorithm just for
> these names (IIRC we already have this, or at least something easily
> modifiable for this purpose, in tree-ssa.c).  This seems like a feasible
> solution, especially if it is only used either after copying larger
> regions (like loop bodies), or after doing all the copying (like in
> the tracer).

Yes, this is approximately what I had in mind (making rewrite_to_ssa
also accept bitmap of SSA_NAMES that are now defined multiple times),
but my last attempt to modify it to do this failed, but I just timeouted
when amount of changes got bit higher than I wanted to do at the moment.

This would solve problems with tracer and other passes.  In meantime
Jeff introduced the scheme of rewriting out and in partially for jump
threading, perhaps we can use it as well?
(that would mean rewriting everything in duplicated region out before
duplication and in after, right?  Or can we do the in/out just after all
the duplication is done (the SSA won't be SSA anymore but stupid
algorithm just rewriting PHI nodes into copies would work, not sure how
smart our's alrogihthm would be)?)

Honza
> 
> Zdenek