[llvm] [Support][KnownFPClass] Refine fdiv and fdiv_self class propagation + some minor fixes for propagateXorSign (PR #215014)

[Max Graey via llvm-commits]

================
@@ -395,13 +399,29 @@ struct KnownFPClass {
   // Propagate knowledge for operations whose result sign is the xor of the
   // operand signs, such as multiply and divide. This only rules out possible
   // non-NaN sign classes. NaNs do not have a constrained sign class here.
-  void propagateXorSign(const KnownFPClass &LHS, const KnownFPClass &RHS) {
-    if ((LHS.isKnownNever(fcNegative) && RHS.isKnownNever(fcNegative)) ||
-        (LHS.isKnownNever(fcPositive) && RHS.isKnownNever(fcPositive)))
+  //
+  // A negative subnormal is read as +0.0 under a positive-zero input mode, so
+  // it counts towards the positive side and not the negative one.
+  //
+  // TODO: With a positive-zero output mode a -sub result is flushed to +0.0, so
+  // the result can be positive after all. Fix it in fmul and fdiv by adding
+  // fcPosZero back and dropping SignBit before they rule out fcSubnormal.
+  void propagateXorSign(const KnownFPClass &LHS, const KnownFPClass &RHS,
+                        DenormalMode Mode) {
+    bool MustFlushNegSub = Mode.Input == DenormalMode::PositiveZero;
+    bool MayFlushNegSub = Mode.inputsMayBePositiveZero();
+
+    FPClassTest NegMask =
+        MustFlushNegSub ? fcNegative & ~fcNegSubnormal : fcNegative;
+    FPClassTest PosMask =
+        MayFlushNegSub ? fcPositive | fcNegSubnormal : fcPositive;
----------------
MaxGraey wrote:

Not sure this is the best way to normalize for input/output modes. Probably better to make separate routine which optinally flush to zero subnormals depend on mode before such operations

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