[llvm] [IndVarSimplify] Introduce `simulateFPIVTripCount` to canonicalize fp loops (PR #169707)

[Antonio Frighetto via llvm-commits]

antoniofrighetto wrote:

> I don't think this is necessary because we have a symbolic brute-force trip count evaluator in `getConstantEvolutionLoopExitValue`. With `-mllvm --scalar-evolution-max-iterations=1000` clang will fold the trip count to 999: https://godbolt.org/z/9E6crKjsn If the comptime overhead is acceptable, we can increase the threshold to align with GCC.
> 
> Can we solve the trip count in `O(lg(abs(exit-init)/abs(incr)))`? We can use binary search since it is monotonic. I am not sure if it works.

Ugh, admittedly missed we could tune that SCEV option, thanks! Though, unlike the proposed brute-force evaluator which runs in O(1), the SCEV evaluator in `computeExitCountExhaustively` scales linearly in the number of instructions involved: `EvaluateExpression` at each step of the recurrence recursively traverses instruction operands to compute the folding for each instruction (done at most once per iteration per caching). Increasing the threshold has an impact on compile time: https://llvm-compile-time-tracker.com/compare.php?from=411a53e16fbc9bfe23fd887c918c3ec5d74fa2bc&to=3664f76578539231eb143bed213715f5ddb360d8&stat=instructions:u. I'll see if this can be ameliorated.

Somehow this doesn't work without having a integer recurrence (https://godbolt.org/z/ahnaqTsdj, though I think this is orthogonal and likely a missed optimization within SCEV, the SCEV evaluator seems to be correctly computing MaxBECount in this case too).

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