[clang] [llvm] Reapply "InstCombine: Introduce SimplifyDemandedUseFPClass"" (PR #74056)

[Andy Kaylor via cfe-commits]

andykaylor wrote:

It seems like there are two possible interpretations of -ffinite-math-only:

1. There will be no NaN or inf values seen anywhere in the program (other than loads and stores?).
2. No floating-point operation (other than compares?) will have NaN or inf inputs or results.

The text of the option in both the clang and gcc documentation says "Allow floating-point optimizations that assume arguments and results are not NaNs or +-inf." That sounds a lot like (1) above, though it could be more clearly stated. "Arguments" sounds like it would refer to arguments in a function call, which in C++ would include operators. Whether or not the operands of an arithmetic operator are "arguments" might be a bit of a semantic argument, but I think it's clear that the option definitely intends to include them. The term "results" is a bit more ambiguous. Does it intend to include return values of any called function? Or does it just mean the results of floating-point operations and math library calls? For quite some time, clang has been marking all functions which return a floating-point value as nnan and ninf when -ffinite-math-only is used.

If you took the second approach, function calls which return a floating-point value wouldn't be marked with the fast-math flags, only floating-point operations. This would be useful for cases like the povray, which uses INF as a sort of sentinel value. Near as I can tell, its calculations don't produce infinities (at least not for inputs I've seen), but it does some comparisons with infinity to see if it needs to process some data. If we had a mode that honored NaN and inf for load, store, and compares, I think it could be useful.

But in a very real sense, this ship has sailed for the -ffinite-math-only option. We have established behavior in the front-end that marks functions which return floating-point values with constructs indicating that they won't return NaN or inf. There are certainly existing optimizations that act on that information (perhaps without even knowing it if they use value tracking). This PR just extends that sort of optimization behavior based on semantics that are already in place.

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