This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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).

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]