That’s what I was expecting to find, but I don’t see a PatFrag for the multiply instruction with the contract flag set. I’m not sure if it’s worth trying to work explicit PatFrags into targets that don’t have them already, since the target-independent combiner seems to be doing what needs to be done in most cases, but I guess each target can make that decision for themselves.
I agree that the global flag should be removed, but I don’t want to break things that are relying on it. The NVPTX backend particularly concerns me because CUDA is the only target that sets the fp-contract state to fast by default (as opposed to HIP which uses fast-honor-pragmas), and also because the NVPTX backend appears to have the most pattern matching that currently relies on the global flag.
I can imagine various front ends wanting to enable contraction unconditionally, but I strongly believe that global flags shouldn’t be enabling any changes to the semantics expressed in the IR. The UnsafeFPMath attribute use worries me less because clang takes care of not setting that unless contract is enabled everywhere in a function, and it is at least something in the IR. I do agree that it should be eliminated though.