[PATCH][RFC] Move IVOPTs closer to RTL expansion

Richard Biener rguenther@suse.de
Tue Sep 10 13:30:00 GMT 2013


On Tue, 10 Sep 2013, Jeff Law wrote:

> On 09/10/2013 02:00 AM, Richard Biener wrote:
> > On Mon, 9 Sep 2013, Steven Bosscher wrote:
> > 
> > > On Mon, Sep 9, 2013 at 10:01 AM, Richard Biener wrote:
> > > > > > > First, the loop passes that at the moment preceede IVOPTs leave
> > > > > > > around IL that is in desparate need of basic re-optimization
> > > > > > > like CSE, constant propagation and DCE.  That puts extra load
> > > > > > > on IVOPTs and its cost model, increasing compile-time and
> > > > > > > possibly confusing it.
> > > 
> > > So why not just run DCE and DOM just before IVOPTs?
> > 
> > Another DCE and DOM?  The patch moving IVOPTs just moves it
> > after the existing DOM (right before the last DCE).
> > 
> > The question is whether we want to pay the compile-time penalty
> > of not making passes deal with dead code, existing full redundancies,
> > not constaint/copy-propagated IL, etc. by inserting these
> > passes over and over in random places.  Of course CSE (being it
> > DOM or FRE) are not exactly cheap.
> Also note, dealing with dead code is simply not possible right now in some
> passes due to lameness in our SSA_NAME interface.
> 
> In particular if a pass wants to remove SSA_NAMEs (releasing them back to the
> name manager), it must remove all references to those names in the IL stream.
> 
> Failure to do so will trigger problems if that pass also tries to create
> SSA_NAMEs.
> 
> Fixing this would allow certain passes (DOM in particular) to clean up better
> after itself rather than wait for cleanup_cfg and friends.

update-ssa for example just queues to release SSA names.  But yes,
re-using SSA names from a freelist has issues and advantages ;)

One solution may be as simple as having the pass manager manage
two SSA name freelists, one a pass allocates from and one it
releases to.  And merge them after each pass.

Of course we'd need to measure impact on SSA namespace density
(which is the whole purpose of the game).

Richard.



More information about the Gcc-patches mailing list