<div dir="ltr"><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_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div class="m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_extra m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_quote m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><blockquote class="m_-3086711547486424248m_-5168355638777027527m_-7849821083040376647quote m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_extra m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div class="gmail_quote m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div class="m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg">Why is it important to track that ?</div></div></div></div></blockquote></div></div></div><div dir="auto" class="m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><br class="m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"></div></div><div dir="auto" class="m_-3086711547486424248m_-5168355638777027527gmail_msg gmail_msg"><div dir="auto" class="m_-3086711547486424248m_-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>So, I'm not really trying to re-litigate this design principle, certainly not in the bottom of this thread. But I equally don't think this patch is the time to change behavior. Note that the original idea was specific to code layout, not other probability-based optimizations. So I wouldn't expect it to impact branch probability.</div><div><br></div><div>But CFG iteration order is *not* what we wanted to preserve. I've not read the patch really, sorry for that. But your other email mentioned that this is more the order of the successor iterators, and I agree that this order isn't interesting in any direction.</div><div><br></div><div>The idea was to use the order of basic blocks in the incoming machine function as the "basis ordering". So, when tie breaking, try to pick a block that is *already* sequenced as a successor, or pick the "nearest" block. That was all.</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"><br class="gmail_msg"></div><div class="gmail_msg">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 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">For optimized build, debuggability should not be the guiding principle.</div></div></div></div></blockquote><div><br></div><div>This is only when we have *no other signal*.</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"><br class="gmail_msg"></div><div class="gmail_msg">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 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">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></div></blockquote><div><br></div><div>Sure, but again, when we *have no signal* we don't have to make this any worse.</div><div><br></div><div>All of this was about: what do we do when we don't have a *reason* to layout the code a particular way. Clearly, if we have some reason everything you say holds.</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">
</blockquote></div></div></div></blockquote></div></div>