
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2017, at 5:33 PM, Chandler Carruth via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Just to explicitly chime in here...<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jan 25, 2017 at 4:32 PM Kyle Butt <<a href="mailto:iteratee@google.com" class="">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="gmail_msg m_-7849821083040376647quote" 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 class=""><br class=""></div><div class="">The idea when Andy and I started the original discussion around MBP was as follows:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Hope this makes sense.</div></div></div></div></blockquote><br class=""></div><div>It makes sense to me. That’s an accurate synopsis. Completely arbitrary code relayout in the absence of PGO or static heuristics is an annoying thing for the compiler to do. That said, I have no idea what’s at stake with the successor order—being deterministic is usually good enough.</div><div><br class=""></div><div>-Andy</div><br class=""></body></html>