[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
+   refactoring to retain quality and integrate continuously.
+
+9. Gradually refactor into multiple VPlan-to-VPlan transforms to reduce
+   complexity:
+
+   a. Simplify initial VPlan construction, by moving complexity to
+      transformations (e.g. adjusting fixed-order recurrences as separate
+      transformation)
+
+   b. Canonicalize then specialize: initial VPlans and early transformations
+      should operate on canonical, target-independent VPlans, to enable general
+      transformations. Target-specific concepts and specialization should be
+      introduced closer to VPlan execution (e.g. introduction of
+      active-lane-mask as VPlan-to-VPlan transformation).
+
+   c. Simplify VPlan execution: reduce the complexity of recipes' *::execute*
+      implementations by breaking up complex recipes and model them more
+      accurately in VPlan. Employ gradual lowering to avoid unnecessary
+      complexity early on and keep canonical VPlans consice by modeling
+      concepts using abstract recipes. Lower or expand such abstract recipes
+      before code-gen to a series of simpler, concrete recipes with simple
+      *::execute* implementations (e.g. using predicated *VPReplicateRecipes* in
+      the early stages of the pipeline, which later get expanded to replicate
+      regions; this simplifes a number of transformations, including sinking, by
+      avoiding having to deal with replicate regions).
+
----------------
npanchen wrote:

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](https://github.com/llvm/llvm-project/pull/82021/files#diff-da321d454a7246f8ae276bf1db2782bf26b5210b8133cb59e4d7fd45d0905decR8291)
* 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

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