[llvm] [LV] Use VPReductionRecipe for partial reductions (PR #144908)

[Sander de Smalen via llvm-commits]

================
@@ -2408,23 +2414,32 @@ class VPInterleaveRecipe : public VPRecipeBase {
   Instruction *getInsertPos() const { return IG->getInsertPos(); }
 };
 
-/// A recipe to represent inloop reduction operations, performing a reduction on
-/// a vector operand into a scalar value, and adding the result to a chain.
-/// The Operands are {ChainOp, VecOp, [Condition]}.
+/// A recipe to represent inloop, ordered or partial reduction operations. It
+/// performs a reduction on a vector operand into a scalar (vector in the case
+/// of a partial reduction) value, and adds the result to a chain. The Operands
+/// are {ChainOp, VecOp, [Condition]}.
 class VPReductionRecipe : public VPRecipeWithIRFlags {
   /// The recurrence kind for the reduction in question.
   RecurKind RdxKind;
   bool IsOrdered;
   /// Whether the reduction is conditional.
   bool IsConditional = false;
+  /// The scaling factor, relative to the VF, that this recipe's output is
+  /// divided by.
+  /// For outer-loop reductions this is equal to 1.
----------------
sdesmalen-arm wrote:

> The main motivation is to use VPMulAccumulateReductionRecipe for partial reductions?

The main motivation is to use VPMulAccumulateReductionRecipe and VPExtendedReductionRecipe, or any future kind of bundled reduction that would equally work for partial reductions. That is because for those bundled representations it does not matter what kind of reductions they are.

Ordered and out-of-order in-loop reductions are already handled by VPReductionRecipe, which are a special kind of a partial reduction. Conversely, a partial reduction is (for one part) an in-loop reduction. Adding partial reductions is therefore a natural extension and can describe both with a single property (VFScaleFactor).

With hindsight, I believe that it was a mistake to keep partial reductions in a separate subclass from all the other ones. If this all would have used the same class from the start, the work done for VPMulAccumulateReductionRecipe, VPExtendedReductionRecipe and VPBundle would all have benefited partial reductions.

I'm not saying that we should always keep this as a single class, but I would first like us to merge the behaviours of partial reductions with the functionality added for in-loop reductions, so that we don't have to keep adding new code specifically for partial reductions, when it can just piggy-back on existing code.

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