This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Move IVOPTs closer to RTL expansion
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Andrew Pinski <pinskia at gmail dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 10 Sep 2013 15:35:05 +0800
- 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>
On Tue, Sep 10, 2013 at 3:30 AM, Steven Bosscher <email@example.com> 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?
>>> >> Second, IVOPTs introduces lowered memory accesses that it
>>> >> expects to stay as is, likewise it produces auto-inc/dec
>>> >> sequences that it expects to stay as is until RTL expansion.
>>> >> Passes such as DOM can break this expectation and make the
>>> >> work done by IVOPTs a waste.
> But IVOPTs leaves its own messy code behind (see below).
>>> >> I remember doing this excercise in the GCC 4.3 timeframe where
>>> >> benchmarking on x86_64 showed no gains or losses (but x86_64
>>> >> isn't very sensitive to IV choices).
>>> >> Any help with benchmarking this on targets other than x86_64
>>> >> is appreciated (I'll re-do x86_64).
> Targets like POWER and ARM would be interesting to test on.
Yes, I will benchmark on ARM 32bit.
>> We already run LIM twice, moving the one that is currently after
>> IVOPTs as well should be easy. But of course as you note IVOPTs
>> may introduce loop invariant code it also may introduce full
>> redundancies in the way it re-writes IVs. And for both people may
>> claim that we have both CSE and LIM on the RTL level, too.
> I would claim that relying on RTL (G)CSE and RTL LIM is a step in the
> wrong direction. You end up creating a lot of garbage RTL, and many
> transformations that are easy on GIMPLE cannot be performed anymore on
> Is it possible to make IVOPTs clean up after itself? It should be easy
> for IVOPTs to notice that it creates loop-invariant code, and position
It would be even better to have some loop-invariant sensitive
re-association, because IVOPT (by using general tree association)
splits loop-invariant expression into different gimple, making lim's
> it on the loop pre-header edge. I suppose full redundancies are
> harder, but I would expect that to happen less frequently (the only
> situation I can think of right now is where a loop is rewritten with
> two IVs where the two IVs share a common sub-expression).