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: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 9 Sep 2013 10:45:51 +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>
On Mon, Sep 9, 2013 at 10:01 AM, Bin.Cheng <firstname.lastname@example.org> wrote:
> On Wed, Sep 4, 2013 at 5:20 PM, Richard Biener <email@example.com> wrote:
>> The patch below moves IVOPTs out of the GIMPLE loop pipeline more
>> closer to RTL expansion. That's done for multiple reasons.
>> 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.
>> 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.
>> 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).
I will bootstrap and make check on arm a15.