<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 30, 2017 at 11:28 AM, Matthias Braun <span dir="ltr"><<a href="mailto:mbraun@apple.com" target="_blank">mbraun@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 30, 2017, at 10:49 AM, Dehao Chen via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_4787973317028569107Apple-interchange-newline"><div><div dir="ltr">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 <a href="https://reviews.llvm.org/D28368" target="_blank">https://reviews.llvm.org/<wbr>D28368</a>, I proposed to double the threshold for loop fully unroller. This will change the codegen of several SPECCPU benchmarks:<div><br></div><div><p style="margin:0px 0px 12px;padding:0px;border:0px;font-family:'segoe ui','segoe ui web regular','segoe ui symbol',lato,'helvetica neue',helvetica,arial,sans-serif;font-size:13px">Code size:<br style="margin-top:0px">447.dealII 0.50%<br>453.povray 0.42%<br>433.milc 0.20%<br>445.gobmk 0.32%<br>403.gcc 0.05%<br>464.h264ref 3.62%</p><p style="margin:0px 0px 12px;padding:0px;border:0px;font-family:'segoe ui','segoe ui web regular','segoe ui symbol',lato,'helvetica neue',helvetica,arial,sans-serif;font-size:13px">Compile Time:<br style="margin-top:0px">447.dealII 0.22%<br>453.povray -0.16%<br>433.milc 0.09%<br>445.gobmk -2.43%<br>403.gcc 0.06%<br>464.h264ref 3.21%</p><p style="margin:0px 0px 12px;padding:0px;border:0px;font-family:'segoe ui','segoe ui web regular','segoe ui symbol',lato,'helvetica neue',helvetica,arial,sans-serif;font-size:13px">Performance (on intel sandybridge):<br style="margin-top:0px">447.dealII +0.07%<br>453.povray +1.79%<br>433.milc +1.02%<br>445.gobmk +0.56%<br>403.gcc -0.16%<br>464.h264ref -0.41%</p><p style="margin:0px 0px 12px;padding:0px;border:0px;font-family:'segoe ui','segoe ui web regular','segoe ui symbol',lato,'helvetica neue',helvetica,arial,sans-serif;font-size:13px">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.</p></div></div></div></blockquote></span><div>Intuitively (correct me if I am wrong) I would think loop unrolling is a more risky operation that is good in many/most cases but can be detrimental to performance (by blowing up code sizes and I-Caches). So I would rather put that into -O3.</div></div></div></blockquote><div><br></div><div>Yes, it applies to runtime/partial loop unroll. That's why we want to set a conservative threshold to make sure unrolled loop does not blow up loop stream detector (LSD) and L1I. But for fully unroll, it only handles cases where loop trip count is small, so the LSD will never activate. By completely flattening the loop, the loop became straight-line code thus we do not have L1I issue for the flattened loop. That's why we think the threshold should be more aggressive for fully unroller.<br></div><div><br></div><div>Dehao</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Matthias</div><div><br></div></font></span></div></div></blockquote></div><br></div></div>