[llvm] [VPlan] Add exit phi operands during initial construction (NFC). (PR #136455)

[via llvm-commits]

================
@@ -2505,35 +2505,43 @@ void VPlanTransforms::handleUncountableEarlyExit(
   VPBuilder EarlyExitB(VectorEarlyExitVPBB);
   for (VPRecipeBase &R : VPEarlyExitBlock->phis()) {
     auto *ExitIRI = cast<VPIRPhi>(&R);
-    PHINode &ExitPhi = ExitIRI->getIRPhi();
-    VPValue *IncomingFromEarlyExit = RecipeBuilder.getVPValueOrAddLiveIn(
-        ExitPhi.getIncomingValueForBlock(UncountableExitingBlock));
-
+    // By default, assume early exit operand is first, e.g., when the two exit
+    // blocks are distinct - VPEarlyExitBlock has a single predecessor.
+    unsigned EarlyExitIdx = 0;
     if (OrigLoop->getUniqueExitBlock()) {
+      // The incoming values currently correspond to the original IR
+      // predecessors. After the transform, the first incoming value is coming
+      // from the original loop latch, while the second operand is from the
+      // early exit. Swap the phi operands, if the first predecessor in the
+      // original IR is not the loop latch.
----------------
ayalz wrote:

Still a seems a bit confusing. Would something like this read clearer:

If VPEarlyExitBlock has two predecessors, they are already ordered such that early exit is second (and latch exit is first), by construction. But its underlying IRBB (EarlyExitIRBB) may have its predecessors ordered the other way around, and it is the order of the latter which corresponds to the order of operands of VPEarlyExitBlock's phi recipes. Therefore, if early exit (UncountableExitingBlock) is the first predecessor of EarlyExitIRBB, we swap the operands of phi recipes, thereby bringing them to match VPEarlyExitBlock's predecessor order, with early exit being last (second). Otherwise they already match.

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