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

[Graham Hunter via llvm-commits]

================
@@ -2370,6 +2370,23 @@ struct VPFirstOrderRecurrencePHIRecipe : public VPHeaderPHIRecipe {
 #endif
 };
 
+// Possible variants of a reduction.
+
+// This reduction is ordered and in-loop.
+struct RdxOrderedInLoop {};
+// This reduction is in-loop.
+struct RdxInLoop {};
+// This reduction isn't partial, ordered or in-loop.
+struct RdxNormal {};
----------------
huntergr-arm wrote:

We can't do the whole reduction out of the loop, there needs to be an update operation inside the loop. For a simple example of an add reduction, we would have something like this for a 'normal' reduction:
```
%header = phi <4 x i32> [ zeroinitializer, %vector.ph ], [ %update, %vector.body ]
...
%update = add <4 x i32> %header, %new.data
...
middle.block
%result = call i32 @llvm.vector.reduce.add(<4 x i32> %update)
```

So there's an update in the loop, but we don't perform any operation across vector lanes until we exit the vector body.

For an in-loop reduction, we would have a scalar phi doing something like this:
```
%header = phi i32 [ 0, %vector.ph ], [ %update, %vector.body ]
...
%in.loop.reduction = call i32 @llvm.vector.reduce.add(<4 x i32> %new.data)
%update = add i32 %header, %in.loop.reduction
...
;; No need for extra operations, as you already have the result
```

Partial reductions are like normal reductions in that they accumulate into a vector in the loop, but the VF of the phi and the VF of the new data don't have to be the same. So there can be some cross-lane reductions, e.g. when going from <8 x i32> to <4 x i32> after the inputs were extended from <8 x i16>.

Ordered reductions are inner loop reductions that produce a scalar, but we must emit an update operation that does not reassociate the update calculations.

(I _think_ I've got that right...)

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