[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