<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 5:33 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just to explicitly chime in here...<br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Jan 25, 2017 at 4:32 PM Kyle Butt <<a href="mailto:iteratee@google.com" target="_blank">iteratee@google.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="m_-5168355638777027527gmail_msg"><div class="m_-5168355638777027527gmail_msg"><div class="gmail_extra m_-5168355638777027527gmail_msg"><div class="gmail_quote m_-5168355638777027527gmail_msg"><blockquote class="m_-5168355638777027527m_-7849821083040376647quote m_-5168355638777027527gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-5168355638777027527gmail_msg"><div class="gmail_extra m_-5168355638777027527gmail_msg"><div class="gmail_quote m_-5168355638777027527gmail_msg"><div class="m_-5168355638777027527gmail_msg">Why is it important to track that ?</div></div></div></div></blockquote></div></div></div><div dir="auto" class="m_-5168355638777027527gmail_msg"><br class="m_-5168355638777027527gmail_msg"></div></div><div dir="auto" class="m_-5168355638777027527gmail_msg"><div dir="auto" class="m_-5168355638777027527gmail_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><br></div></span><div>The idea when Andy and I started the original discussion around MBP was as follows:</div><div><br></div><div>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><br></div><div>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><br></div><div>1) should be considered in branch probablity analysis</div><div>2) use the actual debug source location instead of CFG iterator order as used in Kyle's code. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>1) Principle of least surprise when debugging, performance analyzing, etc. It is very useful if boring C-like code remains in the same basic structure it came in as when the compiler has no good reason to reorder it.</div></div></div></blockquote><div><br></div><div>For optimized build, debuggability should not be the guiding principle.  On the the hand, I can see the usefulness of  option such as -Og  (or even source level directives) which turns on useful optimization but also tries to preserve debuggability of the program.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>2) Reduce surprising churn of order. Basic source code edits that don't re-arrange the order of code shouldn't rearrange the order of generated code. Otherwise, innocuous changes trigger performance regressions that aren't interesting -- the old version got lucky and the new version gets unlucky. There isn't anything to do, but users dislike the surprising noise in their benchmarks.</div></div></div></blockquote><div><br></div><div>This is not necessarily true already. If a branch code condition is changed, it will likely trigger branch prediction to produce very different result.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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><br></div><div>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><br></div><div>For instance, compiler can undo user's unroll with loop re-rolling, undo users inlining with function outlinining etc.</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> 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><br></div><div>Hope this makes sense.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chandler</div></font></span></div></div>
</blockquote></div><br></div></div>