[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one

[Chandler Carruth]

On Sun, Feb 2, 2014 at 9:42 PM, Bob Wilson <bob.wilson at apple.com> wrote:

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

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.


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

Yes, indeed. My change would make the precision issues significantly less
severe, but they're still fundamentally present.


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

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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140202/51acab25/attachment.html>