<div dir="ltr">Just to explicitly chime in here...<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 25, 2017 at 4:32 PM Kyle Butt <<a href="mailto:iteratee@google.com">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="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="m_-7849821083040376647quote 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_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Why is it important to track that ?</div></div></div></div></blockquote></div></div></div><div dir="auto" class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><div dir="auto" class="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><br></div><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><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><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><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. 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><div><br></div><div>-Chandler</div></div></div>