<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">LGTM.<div class=""><br class=""></div><div class="">I did see some regressions running the whole test-suite on the two patches (+ "ST->isCyclone()") we (on our end) might want to look into - I’ll send my results to Gerolf.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Arnold</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 11, 2014, at 9:17 AM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="">james@jamesmolloy.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Arnold, Gerolf, Hal,<div class=""><br class=""></div><div class="">Good idea about a tuning option. Attached is a patch that implements that tuning option. Is it OK to commit?</div><div class=""><br class=""></div><div class="">Gerolf, did you want me to add "|| isCyclone()" to AArch64TargetTransformInfo?</div>
<div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">James</div></div><div class="gmail_extra"><br class=""><br class=""><div class="gmail_quote">On 11 August 2014 04:31, Gerolf Hoflehner <span dir="ltr" class=""><<a href="mailto:ghoflehner@apple.com" target="_blank" class="">ghoflehner@apple.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Typhoon the gain for libquantum is almost 2%, and about one percent on hmmer. No regression on CINT2006. This is O3 LTO, ref input.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
-Gerolf<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
On Aug 8, 2014, at 4:57 PM, Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com" class="">ghoflehner@apple.com</a>> wrote:<br class="">
<br class="">
> I second a tuning option at least in the short term. It is usually hard to get it right, though. So longer term this is a case for dynamic versioning that invokes different versions of the code at run-time depending on the trip count.<br class="">
><br class="">
> -Gerolf<br class="">
><br class="">
> On Aug 8, 2014, at 12:30 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:<br class="">
><br class="">
>> ----- Original Message -----<br class="">
>>> From: "James Molloy" <<a href="mailto:james.molloy@arm.com" class="">james.molloy@arm.com</a>><br class="">
>>> To: "Arnold Schwaighofer" <<a href="mailto:aschwaighofer@apple.com" class="">aschwaighofer@apple.com</a>><br class="">
>>> Cc: "llvm-commits" <<a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a>><br class="">
>>> Sent: Friday, August 8, 2014 9:37:38 AM<br class="">
>>> Subject: [PATCH][LoopVectorizer] Restrict the unroll factor of reductions in loops<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> Hi Arnold,<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> Attached are two patches. The first ups the maximum unroll factor on<br class="">
>>> AArch64 from 2 to 4, for C-A57 only at the moment as that’s all I’ve<br class="">
>>> got data for. This gives us significant wins – ~14% on<br class="">
>>> 462.libquantum at least.<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> However it also causes some regressions. The second patch makes the<br class="">
>>> loop vectorizer a bit more conservative with its unroll factor. The<br class="">
>>> problem is purely for reductions within loops. The regressions I’ve<br class="">
>>> seen are small (but runtime-known) trip count loops within a loop<br class="">
>>> nest. A loop unroll factor of 2 is fine, but above 2 the reduction<br class="">
>>> variable fixup logic after the loop increases the critical path<br class="">
>>> length and resource usage. For most loops this isn’t a problem, but<br class="">
>>> small loops in a larger loop nest will execute this fixup code many<br class="">
>>> times.<br class="">
>><br class="">
>> Can you please add a flag for this? I anticipate needing to tune it.<br class="">
>><br class="">
>> Also, it seems to me that this is exactly the kind of thing that would benefit from profiling information (so we can determine if the inner loop is likely to have a large trip count). Can the current infrastructure do this? Also, maybe in cases where the inner loop count is not a function of the outer loop, we might 'unswitch' it so that we get the unrolled inner loop only when actually profitable.<br class="">
>><br class="">
>> Thanks again,<br class="">
>> Hal<br class="">
>><br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> The heuristic is: if this is a (scalar) reduction, and the loop is<br class="">
>>> nested, clamp the UF to a maximum of 2. With 2, we still get wins<br class="">
>>> but we only add one fadd/fmul to the critical path.<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> Please take a look.<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> Cheers,<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> James<br class="">
>>> _______________________________________________<br class="">
>>> llvm-commits mailing list<br class="">
>>> <a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">
>>><br class="">
>><br class="">
>> --<br class="">
>> Hal Finkel<br class="">
>> Assistant Computational Scientist<br class="">
>> Leadership Computing Facility<br class="">
>> Argonne National Laboratory<br class="">
>><br class="">
>> _______________________________________________<br class="">
>> llvm-commits mailing list<br class="">
>> <a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">
><br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
llvm-commits mailing list<br class="">
<a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">
</div></div></blockquote></div><br class=""></div>
<span id="cid:8B2A585E-77F3-4C87-8A43-9B2E42EF7A7C@apple.com"><limit-scalar-reductions.diff></span><span id="cid:47677C9E-D760-4179-96A0-7BCCE4E00760@apple.com"><up-max-unroll.diff></span></div></blockquote></div><br class=""></div></body></html>