This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rs6000] Update default loop peel limits
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Pat Haugen <pthaugen at linux dot vnet dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Fri, 7 Dec 2012 10:05:06 +0100
- Subject: Re: [PATCH, rs6000] Update default loop peel limits
- References: <50C0FCDE.5010508@linux.vnet.ibm.com> <20121206214313.GG671@atrey.karlin.mff.cuni.cz>
On Thu, Dec 6, 2012 at 10:43 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> The following patch restores the old default limits for loop peeling
>> that were recently changed to 100 and caused a 20% degradation in
>> 454.calculix.
>>
>> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk?
>>
>> -Pat
>>
>>
>> 2012-12-06 Pat Haugen <pthaugen@us.ibm.com>
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Set
>> default loop peeling limits.
>
> Actually the calculix regression is also seen on core.
> Igor was looking into what loops got slower and why. Either we can fix that partiuclar
> loop or revert to the old default (that sadly causes quite a lot of code bloat)
Well, as the patch regressed the testcase in put in the testsuite for calculix
that is no surprise... gfortran.dg/reassoc_4.f. The fix for the testcase was to
increase the limit with a --param :/
Note that it is even beneficial to unroll two more levels of the nest
completely.
It's just an insane testcase (and I spent quite some time on it trying to
somehow autodetect the simplification opportunities - see the unrolling
heuristic rewrite patch I dumped on you a few weeks ago).
No advice from me on how to "fix" this ... but eventually the rewrite restores
the old behavior with the new limits (I did the rewrite to try to somehow make
it do two extra levels of nest unrolling ...).
Richard.
> Honza