[llvm] [VPlan] Introduce ComputeReductionResult VPInstruction opcode. (PR #70253)

[via llvm-commits]

================
@@ -9013,15 +8862,26 @@ void LoopVectorizationPlanner::adjustRecipesForReductions(
     for (VPRecipeBase *R : ReductionPHIList)
       R->moveBefore(*Header, Header->getFirstNonPhi());
 
-  SmallVector<VPReductionPHIRecipe *> InLoopReductionPhis;
   for (VPRecipeBase &R : Header->phis()) {
     auto *PhiR = dyn_cast<VPReductionPHIRecipe>(&R);
-    if (!PhiR || !PhiR->isInLoop() || (MinVF.isScalar() && !PhiR->isOrdered()))
+    if (!PhiR)
+      continue;
+
+    // TODO: At the moment ComputeReductionResult also creates the bc.merge.rdx
+    // phi nodes, hence it needs to be created unconditionally here, until the
+    // reduction resume value handling is also modeled in VPlan.
----------------
ayalz wrote:

Perhaps better keep the creation of bc.merge.rdx outside VPlan, until it can be moved into a suitable recipe and VPBB?
May still "be created unconditionally": ComputeReductionResult finalizes the computation of non in-loop reductions. For in-loop reductions one could (temporarily?) use ComputeReductionResult to represent (and easily retrieve) the ReductionResult, even if no additional Compute is needed, as a form of LCSSA Phi?

Should LV generate an actual LCSSA Phi, i.e., maintain LCSSA form? Note that all VPInstructions are currently excluded from VPRecipeBase::isPhi().

How do we prevent ComputeReductionResult from being treated as dead code, if-not/until hooked-up to a LiveOut.

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