I have some questions regarding some of the details of (mostly instrumentation-based) PGO in LLVM, which I can’t seem to find the answers to on the internet or in the source code:
In general, why do
BranchProbabilityInfouse integers for representing frequencies/probabilities, instead of floating-point numbers?
BlockFrequencyInfo, in BlockFrequency Terminology docs it is said:
Since downstream users need integers (not floating point), this initial frequency assignment is shifted as necessary into the range of
What does this need refer to, and why are integers as frequencies needed?
BranchProbabilityInfo, it has been
uint32_t) since the beginning.
Is this maybe related to simplicity/performance/precision/determinism? In some places,
APFloatare used or referred to as well.
Continuation of the first question: these integer representations in
BlockFrequencyInfocan sometimes hide differences between blocks with frequencies, for example, 0.47 and 0.53, which both become 8/16, when they are scaled here. And then this integer frequency is used to compute profile counts in
BlockFrequencyInfoImplBase::getProfileCountFromFreqin the same file. So this accuracy is considered acceptable, right? I have also found some discussion on
BlockFrequencyInfoaccuracy in https://groups.google.com/g/llvm-dev/c/DElc7PHn5VM. Is the information from there relevant these days?
A question about patch ⚙ D61540 [PGO] Use sum of count values to fix func entry count and add a check to verify BFI counts, which is enabled by default. This changes function entry count metadata in such a way that the sum of computed BFI counters (which scales linearly with the entry count) is the same as the sum of profile data counters. And the reason for this change is said to be:
number pre[c]ision, inconsistent profile, or bugs in BFI.
However, inlining actually subtracts the computed BFI count of the callsite from the callee’s entry count here. Which means that this BFI count, hopefully matched to the profile data, is subtracted from this function entry count, which is scaled and no longer matches the profile data. Is this considered acceptable as well?