[llvm] [LV] Bundle partial reductions inside VPExpressionRecipe (PR #147302)

[Sander de Smalen via llvm-commits]

================
@@ -3520,16 +3532,29 @@ tryToMatchAndCreateMulAccumulateReduction(VPReductionRecipe *Red,
 
   // Clamp the range if using multiply-accumulate-reduction is profitable.
   auto IsMulAccValidAndClampRange =
-      [&](bool isZExt, VPWidenRecipe *Mul, VPWidenCastRecipe *Ext0,
-          VPWidenCastRecipe *Ext1, VPWidenCastRecipe *OuterExt) -> bool {
+      [&](VPWidenRecipe *Mul, VPWidenCastRecipe *Ext0, VPWidenCastRecipe *Ext1,
+          VPWidenCastRecipe *OuterExt) -> bool {
     return LoopVectorizationPlanner::getDecisionAndClampRange(
         [&](ElementCount VF) {
+          if (IsPartialReduction) {
+            // The VF ranges have already been clamped for a partial reduction
+            // and its existence confirms that it's valid, so we don't need to
+            // perform any cost checks or more clamping.
----------------
sdesmalen-arm wrote:

Thanks for clarifying this!

Not something for this PR, but I'd like us to rethink this approach going forward. To me it makes more sense to transform a reduction -> partial reduction (+update the PHI node + middle.block) as part of this (or some other) transform if we find that we can do this more efficiently with partial reductions. Rather than determining this all ahead of time in `collectScaledReductions` and then having our hands tied when we get to this point here. But before we think about that, we should first get this change to land so that we can turn on "maximise vector bandwidth" and benefit from the improved cost-model.

Perhaps it's still worth a FIXME comment to make it clear that this may not be the preferred way of doing things?

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