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

[Andy Kaylor via llvm-commits]

andykaylor wrote:

> > 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!
> 
> I say this is not a bug. The -m flags change the behavior of the machine/codegen, and in this case no FMA instruction was emitted as requested. It was a mechanical request to not emit the FMA instruction. It was not a semantic request to not fuse operations (i.e. not a -f flag)

The C standard says (in a footnote in 6.5) this about the allowance of contracted operation: "This license is specifically intended to allow implementations to exploit fast machine instructions that combine multiple C operators." So if the user is disabling the instructions, why should the compiler still be able to contract the expression? There is no speed benefit, and it decreases numerical consistency. The standard does leave this as implementation-defined behavior and it is basically governed by the FP_CONTRACT state, but it seems to me that it would be more reasonable for the FP_CONTRACT state to default to off when the target doesn't support contracted operations, especially when that support is specifically disabled by user input.

This is getting off track from the current PR, of course. I would still like to hear more about how the situation with the `contract` flag set on an llvm.fmuladd intrinsic occurs, if @vfdff is at liberty to say.

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