On 12/14/2015 05:26 AM, James Greenhalgh wrote:
On Thu, Dec 03, 2015 at 03:07:43PM -0600, Evandro Menezes wrote:
On 11/20/2015 05:53 AM, James Greenhalgh wrote:
On Thu, Nov 19, 2015 at 04:04:41PM -0600, Evandro Menezes wrote:
On 11/05/2015 02:51 PM, Evandro Menezes wrote:
2015-11-05 Evandro Menezes <e.menezes@samsung.com>
gcc/
* config/aarch64/aarch64.c
(aarch64_override_options_internal):
Increase loop peeling limit.
This patch increases the limit for the number of peeled insns.
With this change, I noticed no major regression in either
Geekbench v3 or SPEC CPU2000 while some benchmarks, typically FP
ones, improved significantly.
I tested this tuning on Exynos M1 and on A57. ThunderX seems to
benefit from this tuning too. However, I'd appreciate comments
>from other stakeholders.
Ping.
I'd like to leave this for a call from the port maintainers. I can
see why
this leads to more opportunities for vectorization, but I'm
concerned about
the wider impact on code size. Certainly I wouldn't expect this to
be our
default at -O2 and below.
My gut feeling is that this doesn't really belong in the back-end
(there are
presumably good reasons why the default for this parameter across
GCC has
fluctuated from 400 to 100 to 200 over recent years), but as I
say, I'd
like Marcus or Richard to make the call as to whether or not we
take
this
patch.
Please, correct me if I'm wrong, but loop peeling is enabled only
with loop unrolling (and with PGO). If so, then extra code size is
not a concern, for this heuristic is only active when unrolling
loops, when code size is already of secondary importance.
My understanding was that loop peeling is enabled from -O2
upwards, and
is also used to partially peel unaligned loops for vectorization
(allowing
the vector code to be well aligned), or to completely peel inner
loops
which
may then become amenable to SLP vectorization.
If I'm wrong then I take back these objections. But I was sure this
parameter was used in a number of situations outside of just
-funroll-loops/-funroll-all-loops . Certainly I remember seeing
performance
sensitivities to this parameter at -O3 in some internal workloads
I was
analysing.
Vectorization, including SLP, is only enabled at -O3, isn't it? It
seems to me that peeling is only used by optimizations which already
lead to potential increase in code size.
For instance, with "-Ofast -funroll-all-loops", the total text
size for
the SPEC CPU2000 suite is 26.9MB with this proposed change and 26.8MB
without it; with just "-O2", it is the same at 23.1MB regardless
of this
setting.
So it seems to me that this proposal should be neutral for up to -O2.