[llvm] [VPlan] Introduce child regions as VPlan transform. (PR #129402)
Florian Hahn via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 10 15:17:20 PDT 2025
================
@@ -113,13 +88,6 @@ static bool isHeaderBB(BasicBlock *BB, Loop *L) {
return L && BB == L->getHeader();
}
-void PlainCFGBuilder::setRegionPredsFromBB(VPRegionBlock *Region,
- BasicBlock *BB) {
- // BB is a loop header block. Connect the region to the loop preheader.
- Loop *LoopOfBB = LI->getLoopFor(BB);
- Region->setPredecessors({getOrCreateVPBB(LoopOfBB->getLoopPredecessor())});
-}
-
// Add operands to VPInstructions representing phi nodes from the input IR.
void PlainCFGBuilder::fixHeaderPhis() {
for (auto *Phi : PhisToFix) {
----------------
fhahn wrote:
> Let VPlanCFG0 denote the initial VPlan, constructed from IR. VPlanCFG0 may indeed be a consistent 1-1 translation of the CFG and IR, arguably with all its branches - including early-exits and latch-to-exit (and perhaps unconditional branches too), possibly also representing the BasicBlock operands of phi's and branches as VPValues wrapping these Values, as operands of the corresponding VPIRInstructions.
Yep, I have some follow-up patches to retain the exit branches and keep the exit blocks connected.
In a sense, the specific operand order (1st op = preheader, 2nd op = latch) for header phis is purely a consequence of introducing a region, which itself only has a single predecessor I think. So introducing the canonical order at this point seems like a good fit; the header phis are the only ones which need their order adjusted.
Using a separate recipe for the initial recipes sounds good, something like VPInstruction which always has an underlying instruction would be good, but already models the operands/defs in VPlan via operands. Unfortunately VPIRInstruction is already taken. We would need a version that defines result VPValues and uses VPvalue as operands.
https://github.com/llvm/llvm-project/pull/129402
More information about the llvm-commits
mailing list