[llvm] [VPlan] Add additional guiding principles to docs. (PR #85688)

[Nikolay Panchenko via llvm-commits]

================
@@ -88,6 +88,33 @@ The design of VPlan follows several high-level guidelines:
    detection and formation involves searching for and optimizing instruction
    patterns.
 
+8. The adoption of VPlan components should be done as a gradual, always-on
----------------
npanchen wrote:

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
```c++
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.

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