[llvm] [VPlan] Introduce child regions as VPlan transform. (PR #129402)

[via llvm-commits]

================
@@ -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) {
----------------
ayalz wrote:

> Responding to some comments inline regarding phi/predecessor ordering to start with, to clarify. Would be good to decide first where we want the canonicalization of phi/predecessors to happen.
> 
> Doing it separately from initial VPlan construction has the benefit of reducing the number of special cases needed during initial construction and shifts the complexity of detecting the preheader/latch to a VPlan transform, currently integrated with introducing regions, but could also be a separate canonicalization.

Ah, ok, I see. Sketching how separate canonicalization may look like, for clarify and to help reason about what if anything should be fused:

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.

Let VPlanCFG1 denote the result of canonicalizing VPlanCFG0's phi's and branches according to predecessors/successors order (instead of their BasicBlock operands). It may be better to change the types of recipes used, even when the original predecessor/successor order is retained, to clarify that they belong to distinct VPlan "modes" or "stages". Early-exit branch recipes and successors can be eliminated now.

Let VPlanHCFG0 denote the (first) HCFG VPlan produced by a VPlan transform devoted to canonical-CFG --> HCFG conversion that introduces child (or actually all loop) regions into VPlanCFG1. Would this transform need to update/change any recipes?

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