This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Move IVOPTs closer to RTL expansion
- From: Richard Biener <rguenther at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Andrew Pinski <pinskia at gmail dot com>, "Bin.Cheng" <amker dot cheng at gmail dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 10 Sep 2013 15:23:40 +0200 (CEST)
- Subject: Re: [PATCH][RFC] Move IVOPTs closer to RTL expansion
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 00 dot 1309041115000 dot 20077 at zhemvz dot fhfr dot qr> <CAHFci2-Gyye++CXE2OYs8aORo-c8YuDMKJ2sgQz4UgM-COaJQw at mail dot gmail dot com> <6B21127C-3FFA-4E48-A270-C878C49546E6 at gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1309091000200 dot 3869 at zhemvz dot fhfr dot qr> <CABu31nP611H5=1spXxTh9GJgiNgcjRTCO9jXFnxBZM0UBAfPrA at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1309100951260 dot 3869 at zhemvz dot fhfr dot qr> <522F14A9 dot 9070602 at redhat dot com>
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
> 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).