Not sure I read this correctly, but "always-on refactoring" sounds like "adding ad-hoc changes to adopt some component".
Even though I understand for complex system it's almost impossible to come up with a perfect design that won't change, but should there be at least "perfect at that moment" design that VPlan will pursue with a possible change in mind ?
For example, 3. talks about nested vectorization (multi-level, tenzarization), which is quite complex, but if we consider more down to earth "peel/prolog + main + remainder/epilog/cleanup" loops vectorization, what's expected VPlan representation (just representation, design suppose to include other pieces) ? For instance, it seems to be incorrect to associate VFxUF with a VPlan and will require to introduce it on a VPRegion or something else. My thoughts of this as I expressed in other PR are:

• VPlan class is Module-like object that contains VPlan IR.
• VPCountableLoop class is countable loop-like object in HCFG. VFxUF is associated with it and is propagated to each instruction within
• VPIf class is if-like object in HCFG. Having it outside of the VPCountableLoop treats it as scalar
  ...
  in that case considering simple loop

for (int32_t i = 0; i < e; ++i) {
  red += b[i];
}

for peel + main loops vectorization can be represented as:

VPlan {
  vp.if (<want-to-execute-peel>) {
    vp<%peel.tc> = ...
    vp<%red.initialization> = ...
    vp.loop %i = ir<0>, vp<%peel.tc>, {/*peel vfxuf candidates*/} {
        %red.peel = phi [vp<%red.initialization>, vp<%red.peel.next>] 
        = gep
        = load
        %red.peel.next = 
    }
  }
  vp<%main.start> = phi [0, vp<%peel.tc>]
  vp<%main.tc> = 
  vp.loop %i = vp<%main.start>, vp<%main.tc> {/*main vfxuf candidates*/} {
      %red = phi [vp<%red.peel.next>, vp<%red.next>] 
      = gep
      = load
      %red.next = 
  }
  ir<%red> = reduce %red.next
  vp.loop %i = vp<%main.tc>, ir<N> {scalar} {
      %red.scalar = phi [ir<%red.scalar.next>, ir<%red>] 
      = gep
      = load
      %red.scalar.next = 
  }
};

That said, having couple different examples of "ideal" representation of cases that VPlan should eventually address in the document will be great.

nit: cannot comment on a line 86, but I assume Step 2.b should really be Step 2.ii

Can you please elaborate "reduce complexity" part ? Is it just complexity in terms of building and executing VPlan or something else ?
Essentially, I'm missing what is must and what's nice-to in VPlan. At least my understanding that all transformations in VPlanTransforms, except for VPInstructionsToVPRecipes, are optional.

If I understand correctly rest of it, i.e. initial VPlan should be constructed as-is and all optimizations on it should be done by transforms (optimizations), that looks good. However, I'm also trying to map that point to #82270. Can you please also elaborate which of these principles explains moving canonical iv construction to prepareToExecute ?

Couple more questions/clarifications I'd like to ask:

• Is there a goal to be able to reuse LLVM IR's utils/analyses as much as possible to do VPlan's transformations ? There are cases when that might be beneficial to align API with LLVM's Instructions in future. Currently the only one API I find missing is VPValue::getType(), especially in during initial VPlan construction
• Is it worth to care about downstream compilers ? There are changes we for sure want to upstream, but there could be changes that impossible/hard to upstream. Having VPlan's infrastructure easy-to-extend/change for downstream compilers seems to be a nice-to-have in that document