[compiler-rt] Bfi precision (PR #66285)

[David Li via llvm-commits]

david-xl 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 these costs because the numbers are already saturated. I am measuring a real performance improvement (0.3-0.4%) in this service when I switch to the code from my comment above (with 10 slack bits) 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 #67197 to increase stability in MachineBlockPlacement against small BFI noise.

Do you notice a lot of saturation without EH?

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