[PATCH] [AArch64] Enable partial unrolling and runtime unrolling for AArch64 target

Renato Golin renato.golin at linaro.org
Tue Sep 9 05:31:09 PDT 2014


On 9 September 2014 11:19, Kevin Qin <kevinqindev at gmail.com> wrote:
> I can give more details on the performance regressions here. Basically, partial unrolling contributes small performance improvement, regressions and code size changes. Most of the regressions are caused by the runtime unrolling prologue. This prologue will do some extra work on checking the loop iterations and execute the reminder times of loop bodies. If the runtime unrolled loop is inside another loop, and inner loop count for each running is quite small, then there's a overhead happened in the prologue and caused the regession.

One heuristics that is pretty obvious here is not to add dynamic
checks for inner loops. A better one is to check if the inner loop
induction variable depends only on values external to the inner loop.
Any heuristics that determines that you only need one run-time check,
outside the external loop.


> So I suggest we can enable it first, and then try to get it even better in future.

That's the point, SPEC is *not* "better".

Some are better, others are worse. The geomean doesn't mean that much
on artificial benchmarks. It just means that; for the very restrictive
set of scenarios you're considering, you hurt less than made better,
but that doesn't translate to anything in the wild.

It may be that the conditions that got better here were made
unrealistically large and the ones that got worse weren't, so the
negative impact is proportionally greater, and your geomean would lie
about real world code. You just don't know. Basically, I cannot see
how 50% regressions on any benchmark can be a good thing, regardless
of the wins elsewhere.

I believe Chandler has a good way of testing performance on real world
code, so I'm copying him to have a look at this change. Others might
try on their work loads (do Chromium folks test performance?).


cheers,
--renato




More information about the llvm-commits mailing list