This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop peeling
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Evandro Menezes <e dot menezes at samsung dot com>, Jan Hubicka <hubicka at ucw dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 29 Oct 2014 15:48:48 +0100
- Subject: Re: Loop peeling
- Authentication-results: sourceware.org; auth=none
- References: <033101cff2c7$96bff550$c43fdff0$ at samsung dot com> <CAFiYyc23OhPmV3DJa9z62DB5jwR1JWKowqQDKRyCbrBiKai0xA at mail dot gmail dot com>
> 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?
>
> 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?
There are no real changes in smartness of the heuristics. With profile feedback
we peel average trip count times given by profile (we should use histogram for that)
and without profile feedback it peels constant number of times unless size bound
is met.
To be honest I am not able to think of partiuclarly smart heuristics to handle
peeling. Does anyone have an experience?
Honza
>
> Thanks,
> Richard.
>
> > Thank you,
> >
> > --
> > Evandro Menezes Austin, TX
> >
> >
> >