[PATCH] D106362: [FPEnv][InstSimplify] Enable more folds for constrained fadd

Fri Aug 6 14:16:03 PDT 2021

kpn added inline comments.

================
Comment at: llvm/lib/Analysis/InstructionSimplify.cpp:4908
+      (!RoundingModeMayBe(Rounding, RoundingMode::TowardNegative) &&
+       (ExBehavior != fp::ebStrict || FMF.noNaNs())))
+    if (match(Op1, m_NegZeroFP()))
----------------
kpn wrote:
> spatel wrote:
> > kpn wrote:
> > > sepavloff wrote:
> > > > spatel wrote:
> > > > > sepavloff wrote:
> > > > > > kpn wrote:
> > > > > > > sepavloff wrote:
> > > > > > > > Even if `ExBehavior != fp::ebStrict` this transformation is invalid if `X` is SNaN, the latter must be converted to QNaN.
> > > > > > > > 
> > > > > > > > 
> > > > > > > Can I put this in a different patch? We have the same issue for constrained and non-constrained cases, and we don't have a good way to distinguish them -- nor should we.
> > > > > > > 
> > > > > > > Most of the required code is present in APFloat, but not all. Would it be OK for me to add the needed bits to APFloat and use them from InstSimplify in a different ticket?
> > > > > > 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.
> > > We won't see a NaN here if 'nnan' is specified since simplifyFPOp() will have already turned it to poison and returned. So I think the check for FMF.noNaNs() should be removed since it can't happen and is therefore misleading.
> > > 
> > > We won't fold in the 'strict' exception case because we check for it and reject it.
> > > 
> > > I suspect the real objection is that we're not turning a SNaN into a QNaN here. But with the constant folding that Serge recently added we won't even be here in the "ignore" or "maytrap" cases at all. There won't be a "fadd NaN, -0" case except in the "strict" exception case which we decline to fold.
> > > 
> > > Aside from the unneeded check for FMF.noNaNs() I don't see a problem here. We aren't returning the wrong result here or below.
> > > 
> > > And I do now have code for the APFloat and ConstantFP classes to make it easy for simplifyFPOp() to convert SNaN->QNaN. That's what I was planning on submitting in a different ticket.
> > 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?
> > 
> Actually, the check for FMF.noNaNs() is required to catch non-constants. We can still fold "fadd X, -0" if we know X is not a NaN. We still have the "trivially dead" issue where the instruction would be hanging around needlessly, but still...
Rereading @spatel's comment: what about the "X is a variable that happens to have the value of an SNaN" case: it's true that we'll be removing an instruction that would have converted the SNaN to a QNaN. So the removal of the instruction would be observable. I don't see a way around that without eliminating the ability to optimize at all.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106362/new/

https://reviews.llvm.org/D106362