This is the FP sibling of D43141 with the corresponding IR change in rL327212.
We can't propagate undef here because if a variable operand is a NaN, these binops must propagate NaN. Neither global nor node-level fast-math makes a difference. If we have 'nnan', I think later folds can turn the NaN into undef.
The tests in X86/fp-undef.ll are meant to be the definitive verification for these folds - everything reduces identically now.
The other test changes are collateral damage that I wasn't sure what to do with (see the many test changes I committed in the last day for attempts to preserve functionality independently of this change).
Let me describe those test diffs, and someone with a better understanding may be able to fix those tests:
AArch64/fcvt_combine.ll - we constant folded the fmul, not sure why the expectation was different
AMDGPU/mad-mix-lo.ll - don't know anything about what's happening here
NVPTX/implicit-def.ll - this isn't testing what it intended to test - delete the file.
X86/pr23103.ll - this isn't testing what it intended to test, but I don't know how to do that...could just delete the file?
X86/vector-reduce-fadd.ll and X86/vector-reduce-fmul.ll - I think all of these diffs are the unexpected case where the accumulator param is supposed to be used because it's a strict reduction, but we're passing in undef. Just verifies that we don't crash?
http://llvm.org/docs/LangRef.html#llvm-experimental-vector-reduce-fadd-intrinsic