[llvm-dev] (RFC) Adjusting default loop fully unroll threshold

[Chandler Carruth via llvm-dev]

On Mon, Jan 30, 2017 at 3:51 PM Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Jan 30, 2017, at 10:49 AM, Dehao Chen via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Currently, loop fully unroller shares the same default threshold as loop
> dynamic unroller and partial unroller. This seems conservative because
> unlike dynamic/partial unrolling, fully unrolling will not affect
> LSD/ICache performance. In https://reviews.llvm.org/D28368, I proposed to
> double the threshold for loop fully unroller. This will change the codegen
> of several SPECCPU benchmarks:
>
> Code size:
> 447.dealII 0.50%
> 453.povray 0.42%
> 433.milc 0.20%
> 445.gobmk 0.32%
> 403.gcc 0.05%
> 464.h264ref 3.62%
>
> Compile Time:
> 447.dealII 0.22%
> 453.povray -0.16%
> 433.milc 0.09%
> 445.gobmk -2.43%
> 403.gcc 0.06%
> 464.h264ref 3.21%
>
> Performance (on intel sandybridge):
> 447.dealII +0.07%
> 453.povray +1.79%
> 433.milc +1.02%
> 445.gobmk +0.56%
> 403.gcc -0.16%
> 464.h264ref -0.41%
>
>
> Can you clarify how to read these numbers? (I’m using +xx% to indicates a
> slowdown usually, it seems you’re doing the opposite?).
>
> So considering 464.h264ref, does it mean it is 3.6% slower to compile,
> gets 3.2% larger, and 0.4% slower?
>
> Another question is about PGO integration: is it already hooked there?
> Should we have a more aggressive threshold in a hot function? (Assuming
> we’re willing to spend some binary size there but not on the cold path).
>

I would even wire the *unrolling* the other way: just suppress unrolling in
cold paths to save binary size. rolled loops seem like a generally good
thing in cold code unless they are having some larger impact (IE, the loop
itself is more expensive than the unrolled form).


>
> Thanks,
>
> —
> Mehdi
>
>
> Looks like the change has overall positive performance impact with very
> small code size/compile time overhead. Now the question is shall we make
> this change default in O2, or shall we leave it in O3. We would like to
> have more input from the community to make the decision.
>
> Thanks,
>
> Dehao
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170130/87a2c6f4/attachment.html>