[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