[LLVMdev] Loss of precision with very large branch weights

[Diego Novillo]

On Fri, Apr 24, 2015 at 3:40 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> What does -analyze -branch-prob give?
>

Similar indication of hotness. Both loops appear equally hot.

$ bin/opt -analyze -branch-prob -S unbiased-branches.ll
Printing analysis 'Branch Probability Analysis' for function 'bar':
---- Branch Probabilities ----
Printing analysis 'Branch Probability Analysis' for function 'main':
---- Branch Probabilities ----
  edge entry -> for.cond probability is 16 / 16 = 100% [HOT edge]
  edge for.cond -> for.body probability is 2147483647 / 2147483649 = 100%
[HOT edge]
  edge for.cond -> for.end probability is 2 / 2147483649 = 9.31323e-08%
  edge for.body -> for.inc probability is 16 / 16 = 100% [HOT edge]
  edge for.inc -> for.cond probability is 124 / 124 = 100% [HOT edge]
  edge for.end -> for.cond1 probability is 16 / 16 = 100% [HOT edge]
  edge for.cond1 -> for.body3 probability is 2147483647 / 2147483649 = 100%
[HOT edge]
  edge for.cond1 -> for.end6 probability is 2 / 2147483649 = 9.31323e-08%
  edge for.body3 -> for.inc4 probability is 16 / 16 = 100% [HOT edge]
  edge for.inc4 -> for.cond1 probability is 124 / 124 = 100% [HOT edge]


> But certainly there *is* a limit.  We can't store a ratio of larger
> than ~4B:1.  Is this really a problem?  I understand that you can't
> tell which loop is hotter, but why does that matter?  Is there some
> optimization that will do the wrong thing?  Which one?
>

It will matter for cost analysis in the inliner, for instance.  I don't
think this matters in the few places that profile is used now.  But long
term, we want to make sure that we have a good measure of relative
temperatures within a CFG and across CFGs.


>
> Regarding changing branch weights to 64-bits, I think we should be
> sure it's valuable before we change it.  I imagine it's doable, but
> it'll complicate logic in a few places that don't currently have to
> worry about overflowing `uint64_t`.


Sure, OK. I'll see about making sure we scale things properly during
frequency computation.


Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150424/438f2149/attachment.html>