Re: Loop peeling

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Oct 29, 2014 at 12:53 PM, Tejas Belagod <tejas.belagod@arm.com> wrote:
> On 29/10/14 09:32, Richard Biener wrote:
>>
>> On Tue, Oct 28, 2014 at 4:55 PM, Evandro Menezes <e.menezes@samsung.com>
>> wrote:
>>>
>>> While doing some benchmark flag mining on AArch64, I noticed that
>>> -fpeel-loops was a mined option often.  As a matter of fact, when using
>>> it
>>> always, even without FDO, it seemed to raise most benchmarks and to leave
>>> almost all of the rest flat, with a barely noticeable cost in code-size.
>>> It
>>> seems to me that it might be safe enough to be implied perhaps at -O3.
>>> Is
>>> there any reason why this never came into being?
>
>
> Loop peeling is done by default on AArch64 unless, IIRC,
> -fvect-cost-model=cheap is specified which switches it off. There was a
> general thread on loop peeling around the same time last year
> (https://gcc.gnu.org/ml/gcc/2013-11/msg00307.html) where Richard suggested
> that peeling vs. non-peeling should be factored into the vector cost model
> and is a more generic improvement.

Oh, you are talking about the vectorizer pro-/epilogue loops where we
know a (low) upper bound for the number of iterations.  I think that
is enabled by default at -O3 as it is a "completely peeling" operation.
Only regular peeling which looks at the _estimated_ loop trip count
(peeling that number of times) is guarded by -fpeel-loops.

Richard.

> Thanks,
> Tejas.
>
>
>>
>> Not sure, but peeling is/was very stupid (peeling 8 times unconditionally
>> or not at all).  At least without FDO (and with -fprofile-use it is
>> enabled).
>> Similar case for -funroll-loops.
>>
>> For GCC 5 peeling now moved to GIMPLE, so maybe things changed
>> for that (but I'd doubt that).  Honza?
>
>
>
>
>