[llvm] Bfi precision (PR #66285)

[Matthias Braun via llvm-commits]

MatzeB wrote:

I found that `BlockFrequency` saturation happens a lot in practice. Trying an IPGO enabled service here, I saw hundreds of functions hitting the saturation. This was mostly due to the fact that even nesting two `try/catch` statements pushes the minimum block frequency so far below 1.0 that the current `ScalingFactor = Min.inverse();` even leads to overflow/MAX_UINT saturation on the entry block. To make matters worse I noticed the register allocator often multiplies frequencies with instruction costs and for those cases we loose all of this because the numbers are already saturated. I am measuring a real performance improvement (0.3-0.4%) in this service when I switch to code to the variant above and add some bits (10) as slack so the register allocator and other passes can multiply without triggering immediate saturation.

> In any case, the cases where this matters and overflow occurs are hopefully going to be rare.

If the spread between "min" and "max" frequency is bigger than 64bit then we have to "collapse" on one end (short of replacing the whole system with something like llvm::ScaledNumber or floating point; but that is a discussion for another day I suppose). In the current system I rather collapse the lower-end frequencies to 1 than collapsing the higher end frequencies to MAX_UINT64.


Unfortunately making this change produces a lot of test-case churn. I am still working on this, but published a PR https://github.com/llvm/llvm-project/pull/67197 to increase stability in MachineBlockPlacement against small BFI noise.

https://github.com/llvm/llvm-project/pull/66285