<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>