
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 14, 2011, at 1:32 AM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Nov 14, 2011 at 1:11 AM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@googlemail.com">benny.kra@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 14.11.2011, at 10:00, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>

<br>

> Author: chandlerc<br>

> Date: Mon Nov 14 02:55:59 2011<br>

> New Revision: 144527<br>

><br>

> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=144527&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=144527&view=rev</a><br>

> Log:<br>

> Reuse the logic in getEdgeProbability within getHotSucc in order to<br>

> correctly handle blocks whose successor weights sum to more than<br>

> UINT32_MAX. This is slightly less efficient, but the entire thing is<br>

> already linear on the number of successors. Calling it within any hot<br>

> routine is a mistake, and indeed no one is calling it. It also<br>

> simplifies the code.<br>

<br>

</div>Does this problem also exist in the non-machine BPI version of getHotSucc?<br></blockquote><div><br></div><div>At a fundamental level, yes. But I'm not sure we really care.</div><div><br></div><div>At the IR level, we *compute* the branch probabilities. If the structure of the program is changed radically, we *recompute* them rather than updating them in-place. The computation (in the BPI analysis pass) is careful to eagerly scale weights down such that the sum doesn't overflow. So the assertion (and the lack of code to handle it) seem fine there.</div>

<div><br></div><div>At the machine code level, we are updating the weights of the edges in the few places where they are mutated. That's what causes trouble. My suspicion is critical edge splitting, but I've not dug too deeply into it.</div>

<div><br></div><div>So essentially, I don't think the IR-level code is really subject to the bug, despite having the same inability to cope with overflow.</div></div></blockquote><div><br></div><div>Assuming the sum of edges doesn't overflow is not a bug, it's a very deliberate design feature. Preserving the analysis across CFG updates wasn't implemented, and the "bug" that Chandler is suffering from is that we enabled this code implying it was sufficiently implemented without any safeguards or even documenting the limitations.</div><div><br></div><div>Scaling the edges was part of the original design, but it was supposed to happen in setEdgeWeight, not getEdgeWeight. The weights are currently only set by the static estimator, so we didn't need an intelligent API. For general CFG manipulation, we definitely need a wrapper around setEdgeWeight that scales the edges automatically.</div><div><br></div><div>-Andy</div><br><blockquote type="cite">

_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br></blockquote></div><br></body></html>