<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 9:42 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":c7a" style="overflow:hidden">Adding a confidence dimension seems like overkill to me. It seems like we should be able to distinguish branches with known 50/50 probability, e.g., from real profile data, from those where we have no idea, simply by omitting the branch probability information in the latter case. I suppose that is essentially adding a confidence dimension, but only in a very simple way.<br>
</div></blockquote><div><br></div><div>BranchProbabilityInfo exposes *some* probability for every branch as a significant simplification to the consumers. I don't think we want to trivially give this property up.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":c7a" style="overflow:hidden">
<br>
That’s a separate question from what to do when you don’t know anything about the probability of a branch. Andy has thought a lot more about this than I have, so for now, I will defer to his opinion. I will just point out that Duncan Exon Smith is currently looking at rewriting the BlockFrequency pass in a way that Jakob had suggested to help fix some serious problems with the loss of precision. Your proposed change to BlockFrequency would almost certainly have an impact on his work, so hopefully we can figure out soon what we want to do.<br>
</div></blockquote><div><br></div><div>Yes, indeed. My change would make the precision issues significantly less severe, but they're still fundamentally present.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":c7a" style="overflow:hidden">Incidentally, while looking at this, I noticed that our current static heuristics are assigning naive 50/50 probabilities due to a bug. I filed PR18705 to describe it, but basically we’re often doing the wrong thing for anything inside a loop.</div>
</blockquote></div><br>Yea, just a bug. Most of the profile input that I care about comes before the loop heuristic though, so this hasn't been hurting us heavily. I do worry that it may have been hiding significant static heuristic problems further down the stack.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>