<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 25, 2017 at 6:18 PM Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Wed, Jan 25, 2017 at 5:33 PM, Chandler Carruth <span dir="ltr" class="gmail_msg"><<a href="mailto:chandlerc@gmail.com" class="gmail_msg" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Just to explicitly chime in here...<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Jan 25, 2017 at 4:32 PM Kyle Butt <<a href="mailto:iteratee@google.com" class="gmail_msg" target="_blank">iteratee@google.com</a>> wrote:</div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_extra m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_quote m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><blockquote class="m_4395611811810752577m_-5168355638777027527m_-7849821083040376647quote m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_extra m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_quote m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg">Why is it important to track that ?</div></div></div></div></blockquote></div></div></div><div dir="auto" class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><br class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"></div></div><div dir="auto" class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg"><div dir="auto" class="m_4395611811810752577m_-5168355638777027527gmail_msg gmail_msg">Chandler can back me up here, but front ends and users rely on source order of branches being a slight hint in the absence of other evidence. Going through in a second pass the only way to preserve that is to somehow record the order of the first pass. Stable sort just doesn't keep enough information.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">The idea when Andy and I started the original discussion around MBP was as follows:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In some cases we won't have good profile signals or good CFG structure signals. In those cases, we should preserve source order of code for three reasons in decreasing order of importance:</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Static prediction heuristics use many different signals, but I am not aware of any using source locations. If there is such heuristic which proves to be useful, it</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) should be considered in branch probablity analysis</div><div class="gmail_msg">2) use the actual debug source location instead of CFG iterator order as used in Kyle's code. </div></div></div></div></blockquote><div><br></div><div>FWIW Andy and I noticed this when doing scheduling work as well. Basically use the source ordering as a tie breaker in cases where each branch is equally profitable. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">3) If a benchmark has source order that leads to faster code layout than some other order, the compiler shouldn't break that in the case where it has no good information.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">User can always annotate branches with __builtin_expect to give compiler hint. It is not reasonable for the optimizing compiler to assume user has made the the best possible decisions -- which often in times are wrong.</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></blockquote><div><br></div><div>Agreed, but I'm not a huge fan of annotating branches.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">For instance, compiler can undo user's unroll with loop re-rolling, undo users inlining with function outlinining etc.</div></div></div></div></blockquote><div><br></div><div>It can, but take something like the hot hand unrolled loop from something like John the Ripper here - basically the user already scheduled the code to maximize ILP for the function, if we choose source order for our tie break then we can keep the tuning that the user gave.</div><div><br></div><div>I'm not saying that this is the best method to determine any of this, just giving a bit more background as to what we were thinking at the time.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">David</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> I think this was more important before we had good PGO, but I think it remains mildly useful. In some ways, its just an extension of #2.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Hope this makes sense.</div><span class="m_4395611811810752577HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Chandler</div></font></span></div></div>
</blockquote></div></div></div></blockquote></div></div>