[PATCH] D103289: A post-processing for BFI inference

David Li via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 4 14:16:24 PDT 2021


davidxl added inline comments.


================
Comment at: llvm/include/llvm/Analysis/BlockFrequencyInfoImpl.h:1489
+    }
+    if (OneMinusSelfProb != Scaled64::getOne())
+      NewFreq /= OneMinusSelfProb;
----------------
spupyrev wrote:
> davidxl wrote:
> > spupyrev wrote:
> > > davidxl wrote:
> > > > Does it apply to other backedges too?
> > > not sure I fully understand the question, but we need an adjustment only for self-edges; blocks without self-edges don't need any post-processing
> > > 
> > > I added a short comment before the loop
> > NewFreq /= OneMinusSelfProb looks like multiply the block freq (one iteration loop) with the average trip count -- that is why I asked if this applies to other backedges.
> Here is the relevant math:
> 
> we want to find a new frequency for block I, `Freq[I]`, such that it is equal to `\sum Freq[J] * Prob[J][I]`, where the sum is taken over all (incoming) jumps (J -> I). These are "ideal" frequencies that BFI is trying to compute.
> 
> Clearly if I-th block has no self-edges, then we simply assign `Freq[I]:=\sum Freq[J] * Prob[J][I]` (that is, no adjustment). However, if there are self_edges, we need to assign `Freq[I]:=(\sum Freq[J] * Prob[J][I]) / (1 - Prob[I][I])` (the adjustment in the code)
I wonder why the special treatment is needed in the first place.

Suppose we have 

 ```
 BB1  (init freq = 50)
     |
     V  <-----------------
    BB2 (int freq = 0)   |
    /      \ 90%              |
   / 10%\____________|
<

```

With iterative fixup, BB2's frequency will converge to 500, which is the right value without any special handling.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103289/new/

https://reviews.llvm.org/D103289



More information about the llvm-commits mailing list