[llvm] [VPlan] Add VPIRInstruction, use for exit block live-outs. (PR #100735)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 13 13:58:40 PDT 2024


================
@@ -8647,13 +8647,17 @@ static MapVector<PHINode *, VPValue *> collectUsersInExitBlock(
   // from scalar loop only.
   if (MiddleVPBB->getNumSuccessors() != 2)
     return {};
-  MapVector<PHINode *, VPValue *> ExitingValuesToFix;
-  BasicBlock *ExitBB =
-      cast<VPIRBasicBlock>(MiddleVPBB->getSuccessors()[0])->getIRBasicBlock();
+  MapVector<VPIRInstruction *, VPValue *> ExitingValuesToFix;
+  VPBasicBlock *ExitVPBB = cast<VPIRBasicBlock>(MiddleVPBB->getSuccessors()[0]);
   BasicBlock *ExitingBB = OrigLoop->getExitingBlock();
-  for (PHINode &ExitPhi : ExitBB->phis()) {
-    Value *IncomingValue =
-        ExitPhi.getIncomingValueForBlock(ExitingBB);
+  for (VPRecipeBase &R : *ExitVPBB) {
+    auto *IR = dyn_cast<VPIRInstruction>(&R);
+    if (!IR)
+      continue;
+    auto *ExitPhi = dyn_cast<PHINode>(&IR->getInstruction());
+    if (!ExitPhi)
+      break;
----------------
fhahn wrote:

> Breaking because all remaining recipes are expected to be non phi's

Yes.

> Should the lcssa VPIRI's be considered phi recipes (as do loop header phi recipes) to help ensure they appear before non-phi recipes (VPIRI's) in the VP(IR)BB?

We could but this would pull in more complexity in this patch without much benefits initially. Perhaps better done once a more concrete need arises/as follow up?


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


More information about the llvm-commits mailing list