[llvm] [InstCombine] Canonicalize reassoc contract fmuladd to fmul + fadd (PR #90434)

[Andy Kaylor via llvm-commits]

andykaylor wrote:

> > I've added emphasis on the first condition, because we aren't currently respecting this condition in the constant folder. The constant folder will fold llvm.fmuladd as if it were a fused operation even if the target instruction set does not support FMA.
> 
> I think we should just drop the first line in the description. The intention and implementation is to do whatever is contextually faster. A target may only choose to fuse specific callsites, and isn't required to consistently fuse every call. We can't define the IR in terms of ISA features, and just because an ISA has the features does not mean the fused operations are always faster.

Maybe the front end shouldn't be generating llvm.fmuladd() if the target doesn't support FMA. The problem I have here is that it's difficult to explain to a customer that they didn't get consistent numeric results because of fused operations when they're compiling for a target that doesn't support FMA. You might ask, why is the user enabling contraction if they are compiling for a target that doesn't support contraction? The reason is that the default behavior of clang is FP_CONTRACT ON.

Here's something that looks like a clear bug in the front end -- the front end will generate the llvm.fmuladd() intrinsic even if I've explicitly disabled FMA with the -mno-fma option!

https://godbolt.org/z/xab8Pa779

If you're compiling for a target that does support FMA and you have contract enabled, I think it's fine for the optimizer to constant fold it either way, but if we can be certain that the operation will never be fused at execution time, the optimizer shouldn't be folding it without intermediate rounding.

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