I am not sure I understand what you are going to put into another patch. The transformation:

fadd X, -0 ==> X

is valid only if X != SNaN, otherwise we have:

fadd SNaN, -0 ==> QNaN

It does not depend on whether FP environment is default or not, the code before your changes was already incorrect. Such transformation is valid if the operation has flag nnan, but not in general case. Code in APFloat hardly can help, as constant folding is made previously, if X is a constant here, it means it cannot be folded.

IIUC, you are saying SNaN vs. QNaN is more than just a part of the exception state. But that's not how I interpret the current LangRef:
https://llvm.org/docs/LangRef.html#floating-point-environment

...and that's why *none* of the transforms here are intentionally SNaN preserving/clearing.

If we are going to change the behavior of the default FP env, the LangRef must be updated to make that clear. I don't see the motivation yet.

That's true for default FP environment. A difference between SNaN and QNaN is that operations on SNaN raise invalid exception. In default FP environment exceptions are ignored so SNaN and QNaN behave identically.

But this code works in non-default FP environment as well. fadd here designates both regular IR node used in default environment as well as its constrained counterpart. So SNaN here must be handled more carefully.

This seems to be getting fuzzy when the exception state is "MayTrap", so we probably need to clarify that definition in the LangRef.

Is there a regression test below that shows where you think this patch is wrong?

I think the fold is correct with MayTrap (assuming the rounding mode is known suitable) because "passes are not required to preserve all exceptions that are implied by the original code"; presumably some other operation is eventually going to generate the invalid exception when it sees the SNaN?

I don't think you can make this transformation in the "maytrap" case. It would be ok to optimize an SNaN to a QNaN, but you can't eliminate an instruction that would raise the exception while performing the same conversion. Consider this example:

double foo(double x, double y) {
 #pragma clang fp exceptions(maytrap)
  double temp;
  feclearexcept(FE_ALL_EXCEPT);
  temp = x + -0.0;
  // Check the x = SNaN case
  if (fetestexcept(FE_INEXACT))
    return -1.0;
  temp = temp + y;
  // Check the y = SNaN case
  if (fetestexcept(FE_INEXACT))
    return -2.0;
  return temp;
}

Eliminating the fadd x, -0 causes the exception to be raised in the wrong place.

The transformation fadd X, -0 ==> X is wrong in the two cases:

1. When the rounding mode is downward and X is +0: +0 + (-0) ==> -0. If MFM has flag nsz, I think we can apply this transformation.

2. When X is a signaling NaN: SNaN + (-0) ==> QNaN. In runtime the operation would produce quiet NaN but it this transformation is done, the result would be signaling NaN.

It is not correct to produce SNaN instead of QNaN. This result might be stored somewhere and could further be processed by other code, which operates in strict mode. Such transformation would cause that code to trap. Behavior of the code with this transformation and without it would be different. So this transformation is safe only if FMF.noNans().

The proposed condition is:

if ((!RoundingModeMayBe(Rounding, RoundingMode::TowardNegative) || FMF.noSignedZeros())
    && FMF.noNaNs())

According to https://en.wikipedia.org/wiki/Signed_zero:

"x-x=x+(-x)=+0 (for any finite x, -0 when rounding toward negative)"

So the check for rounding mode is also necessary, unless FMF.noSignedZero().