<div dir="ltr">The general direction here seems fine (we should re-evaluate these kinds of thresholds from time to time).<div><br></div><div>The other high level question I have here is: why 2x? Why not 4x?<div><br></div><div>I think it would be good to show some data from a reasonable spread and where some reasonable point is in the curve to draw the line.</div><div><br></div><div>I'm also mildly worried about basing something like this on SPEC which involves relatively small programs. It might be good to ask others to provide data as well on code size / performance tradeoffs for larger applications. (Chrome for example.)</div><div><br></div><div>And it might be worth writing down the methodology used to set the thresholds so we start gaining some consistency on this front.<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 30, 2017 at 4:59 PM Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br></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" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Jan 30, 2017, at 4:56 PM, Dehao Chen <<a href="mailto:dehao@google.com" class="gmail_msg" target="_blank">dehao@google.com</a>> wrote:</div><br class="m_-6293897042106820945Apple-interchange-newline gmail_msg"><div class="gmail_msg"><br class="m_-6293897042106820945Apple-interchange-newline gmail_msg"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_quote gmail_msg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Mon, Jan 30, 2017 at 3:56 PM, Chandler Carruth<span class="m_-6293897042106820945Apple-converted-space gmail_msg"> </span><span dir="ltr" class="gmail_msg"><<a href="mailto:chandlerc@google.com" class="gmail_msg" target="_blank">chandlerc@google.com</a>></span><span class="m_-6293897042106820945Apple-converted-space gmail_msg"> </span>wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_-6293897042106820945h5 gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Jan 30, 2017 at 3:51 PM Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><blockquote type="cite" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">On Jan 30, 2017, at 10:49 AM, Dehao Chen via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-6293897042106820945m_-4486181801685859403m_3793832598303836648Apple-interchange-newline m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div dir="ltr" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">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" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" target="_blank">https://reviews.llvm.org/D28368</a>, I proposed to double the threshold for loop fully unroller. This will change the codegen of several SPECCPU benchmarks:<div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><p class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" 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 class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="margin-top:0px">447.dealII 0.50%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">453.povray 0.42%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">433.milc 0.20%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">445.gobmk 0.32%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">403.gcc 0.05%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">464.h264ref 3.62%</p><p class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" 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 class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="margin-top:0px">447.dealII 0.22%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">453.povray -0.16%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">433.milc 0.09%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">445.gobmk -2.43%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">403.gcc 0.06%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">464.h264ref 3.21%</p><p class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" 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 class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="margin-top:0px">447.dealII +0.07%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">453.povray +1.79%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">433.milc +1.02%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">445.gobmk +0.56%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">403.gcc -0.16%<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">464.h264ref -0.41%</p></div></div></div></blockquote></div></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><blockquote type="cite" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></blockquote><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">Can you clarify how to read these numbers? (I’m using +xx% to indicates a slowdown usually, it seems you’re doing the opposite?).</div></div></div></blockquote></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As this is comparing spec scores instead of run time, +xx% here means speedup, -xx% means slowdown.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_-6293897042106820945h5 gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">So considering 464.h264ref, does it mean it is 3.6% slower to compile, gets 3.2% larger, and 0.4% slower?</div></div></div></blockquote></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">That is correct. The 0.4% slowdown is in the run-to-run noise range.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Ok, thanks for the clarifications.</div><div class="gmail_msg">What about the noise on the improvements? How reliable are you other numbers on this aspect?</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_-6293897042106820945h5 gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">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).</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg">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).</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Agree that we could suppress unrolling in cold path to save code size. But that's orthogonal with the propose here. This proposal focuses on O2 performance: shall we have different (higher) fully unroll threshold than dynamic/partial unroll.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I agree that this is (to some extent) orthogonal, and it makes sense to me to differentiate the threshold for full unroll and the dynamic/partial case.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">— </div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Mehdi</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_msg">We can have a separate patch to further boost threshold for hot loops and suppress unrolling for cold loops. One concern is that in order to check if a loop is hot/cold, we will need BFI for the loop pass. In the legacy loop pass manager, this will insert a function pass in the middle of a series of loop passes.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Dehao</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">Thanks,</div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">— </div></div></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">Mehdi</div></div></div><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" style="word-wrap:break-word"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><blockquote type="cite" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div dir="ltr" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><div class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><p class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" 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><p class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" 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">Thanks,</p><p class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" 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">Dehao</p></div></div>_______________________________________________<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">LLVM Developers mailing list<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><a href="mailto:llvm-dev@lists.llvm.org" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"></div></blockquote></div></div>_______________________________________________<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg">LLVM Developers mailing list<br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><a href="mailto:llvm-dev@lists.llvm.org" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="m_-6293897042106820945m_-4486181801685859403gmail_msg gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></blockquote></span></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></div></div>