Rename the VECREDUCE_STRICT_{FADD,FMUL} SDNodes to VECREDUCE_SEQ_{FADD,FMUL}.

[aemerson]

Summary

The STRICT was causing unnecessary confusion. I think SEQ is a more accurate name for what they actually do, and the other obvious option of "ORDERED" has the issue of already having a meaning in FP contexts.

[dmgreen]

AArch64 calls these "strictly-ordered reductions". If those two words are off the table then SEQ sounds fine to me providing we explain what that means (which we do).

llvm/include/llvm/CodeGen/ISDOpcodes.h

1109–1124

-> These reductions are not strictly ordered, ...

[aemerson]

Reword comment.

[nikic]

The STRICT was causing unnecessary confusion. I think SEQ is a more accurate name for what they actually do, and the other obvious option of "ORDERED" has the issue of already having a meaning in FP contexts.

Out of curiosity, what is the existing usage of "ordered" that conflicts with this one?

[RKSimon]

llvm/include/llvm/CodeGen/ISDOpcodes.h

1108–1109

To avoid ambiguity - please can you add a codesnippet to the comment showing the order? Maybe something similar to relaxed variants below showing possible expansions (and maybe what the default legalizing expansion is?).

[aemerson]

In D88791#2310583, @nikic wrote:

The STRICT was causing unnecessary confusion. I think SEQ is a more accurate name for what they actually do, and the other obvious option of "ORDERED" has the issue of already having a meaning in FP contexts.

Out of curiosity, what is the existing usage of "ordered" that conflicts with this one?

Ordered FP comparisons, e.g. the "oeq" condition code.

llvm/include/llvm/CodeGen/ISDOpcodes.h

1108–1109

Sure, will do.

[aemerson]

Add more comments.

[RKSimon]

llvm/include/llvm/CodeGen/ISDOpcodes.h

1108–1109

Shouldn't that be:

RES = VECREDUCE_SEQ_FADD float ACC, <4 x float> SRC_VEC

1109–1124

Check types - FADD or ADD ?

[aemerson]

Oops, brain was still in the fp-typeless GISel world. Fix types to f32/f16.

[dmgreen]

llvm/include/llvm/CodeGen/ISDOpcodes.h

1120–1122

We are nitpicking at this point, but should it be using updated variables:

///   PART_RDX = FADD SRC_VEC[0:3], SRC_VEC[4:7]
///   PART_RDX2 = FADD PART_RDX[0:1], PART_RDX[2:3]
///   RES = FADD PART_RDX2[0], PART_RDX2[1]

[aemerson]

Remove the scalar input overload for fadd/fmul. Now the signature is simple llvm.reduce.fadd.v4f32 rather than llvm.reduce.fadd.f32.v4f32

Also fix some langref formatting, and fold in the change to use "sequential" instead of "ordered" while I'm there.

[aemerson]

Sigh, attached patch to wrong review. Ignore that update, reverting to earlier version.

[dmgreen]

The accidental ping worked :)

LGTM

[RKSimon]

LGTM

llvm/include/llvm/CodeGen/ISDOpcodes.h

 
   /// VSCALE(IMM) - Returns the runtime scaling factor used to calculate the
   /// number of elements within a scalable vector. IMM is a constant integer
   /// multiplier that is applied to the runtime value.
   VSCALE,
 
   /// Generic reduction nodes. These nodes represent horizontal vector
   /// reduction operations, producing a scalar result.
-  /// The STRICT variants perform reductions in sequential order. The first
+  /// The SEQ variants perform reductions in sequential order. The first
   /// operand is an initial scalar accumulator value, and the second operand
   /// is the vector to reduce.
-  VECREDUCE_STRICT_FADD,
-  VECREDUCE_STRICT_FMUL,
-  /// These reductions are non-strict, and have a single vector operand.
+  /// E.g. RES = VECREDUCE_SEQ_FADD f32 ACC, <4 x f32> SRC_VEC
+  ///  ... is equivalent to
+  /// RES = (((ACC + SRC_VEC[0]) + SRC_VEC[1]) + SRC_VEC[2]) + SRC_VEC[3]
+  VECREDUCE_SEQ_FADD,
+  VECREDUCE_SEQ_FMUL,
+
+  /// These reductions have relaxed evaluation order semantics, and have a
+  /// single vector operand. The order of evaluation is unspecified. For
+  /// pow-of-2 vectors, one valid legalizer expansion is to use a tree
+  /// reduction, i.e.:
+  /// For RES = VECREDUCE_FADD <8 x f16> SRC_VEC
+  ///   PART_RDX = FADD SRC_VEC[0:3], SRC_VEC[4:7]
+  ///   PART_RDX2 = FADD PART_RDX[0:1], PART_RDX[2:3]
+  ///   RES = FADD PART_RDX2[0], PART_RDX2[1]
+  /// For non-pow-2 vectors, this can be computed by extracting each element
+  /// and performing the operation as if it were scalarized.
   VECREDUCE_FADD,
   VECREDUCE_FMUL,
   /// FMIN/FMAX nodes can have flags, for NaN/NoNaN variants.
   VECREDUCE_FMAX,
   VECREDUCE_FMIN,
   /// Integer reductions may have a result type larger than the vector element
   /// type. However, the reduction is performed using the vector element type
   /// and the value in the top bits is unspecified.

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

void SelectionDAGBuilder::visitVectorReduce(const CallInst &I,
 
   switch (Intrinsic) {
   case Intrinsic::vector_reduce_fadd:
     if (SDFlags.hasAllowReassociation())
       Res = DAG.getNode(ISD::FADD, dl, VT, Op1,
                         DAG.getNode(ISD::VECREDUCE_FADD, dl, VT, Op2, SDFlags),
                         SDFlags);
     else
-      Res = DAG.getNode(ISD::VECREDUCE_STRICT_FADD, dl, VT, Op1, Op2, SDFlags);
+      Res = DAG.getNode(ISD::VECREDUCE_SEQ_FADD, dl, VT, Op1, Op2, SDFlags);
     break;
   case Intrinsic::vector_reduce_fmul:
     if (SDFlags.hasAllowReassociation())
       Res = DAG.getNode(ISD::FMUL, dl, VT, Op1,
                         DAG.getNode(ISD::VECREDUCE_FMUL, dl, VT, Op2, SDFlags),
                         SDFlags);
     else
-      Res = DAG.getNode(ISD::VECREDUCE_STRICT_FMUL, dl, VT, Op1, Op2, SDFlags);
+      Res = DAG.getNode(ISD::VECREDUCE_SEQ_FMUL, dl, VT, Op1, Op2, SDFlags);
     break;
   case Intrinsic::vector_reduce_add:
     Res = DAG.getNode(ISD::VECREDUCE_ADD, dl, VT, Op1);
     break;
   case Intrinsic::vector_reduce_mul:
     Res = DAG.getNode(ISD::VECREDUCE_MUL, dl, VT, Op1);
     break;
   case Intrinsic::vector_reduce_and:

llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp

case ISD::CONDCODE:
     case ISD::SETNE:                    return "setne";
 
     case ISD::SETTRUE:                  return "settrue";
     case ISD::SETTRUE2:                 return "settrue2";
     case ISD::SETFALSE:                 return "setfalse";
     case ISD::SETFALSE2:                return "setfalse2";
     }
   case ISD::VECREDUCE_FADD:             return "vecreduce_fadd";
-  case ISD::VECREDUCE_STRICT_FADD:      return "vecreduce_strict_fadd";
+  case ISD::VECREDUCE_SEQ_FADD:         return "vecreduce_seq_fadd";
   case ISD::VECREDUCE_FMUL:             return "vecreduce_fmul";
-  case ISD::VECREDUCE_STRICT_FMUL:      return "vecreduce_strict_fmul";
+  case ISD::VECREDUCE_SEQ_FMUL:         return "vecreduce_seq_fmul";
   case ISD::VECREDUCE_ADD:              return "vecreduce_add";
   case ISD::VECREDUCE_MUL:              return "vecreduce_mul";
   case ISD::VECREDUCE_AND:              return "vecreduce_and";
   case ISD::VECREDUCE_OR:               return "vecreduce_or";
   case ISD::VECREDUCE_XOR:              return "vecreduce_xor";
   case ISD::VECREDUCE_SMAX:             return "vecreduce_smax";
   case ISD::VECREDUCE_SMIN:             return "vecreduce_smin";
   case ISD::VECREDUCE_UMAX:             return "vecreduce_umax";