[VPlan] Document current status. #85689
Conversation
Update VectorizationPlan.rst to include a section about the current status of VPlan and its use in LoopVectorize, based on "VPlan: Status Update and Future Roadmap", LLVM Developers’ Meeting 2023, https://www.youtube.com/watch?v=SzGP4PgMuLE Preview a rendered version here: https://gist.github.com/fhahn/c4a6d7121b86904ab5e0fdf30ab54940/raw/45bea52de83f4ab500a534d2627d8d6a101cb390/VectorizationPlan-CurrentStatus.pdf
llvm/docs/VectorizationPlan.rst
Outdated
| VPlan-based analyses and transformations are used to simplify and modularize | ||
| the vectorization process [10]_. Those include transformations to | ||
|
|
||
| 1. Legalize the initial VPlan, e.g. by introducing specializedrecipes for |
There was a problem hiding this comment.
specializedrecipes -> specialized recipes
| Current Status | ||
| ============== | ||
| VPlan is currently used to drive code-generation in LoopVectorize. VPlans are | ||
| constructed after all cost-based and most legality-related decisions have been |
There was a problem hiding this comment.
VPlans are constructed after all cost-based ... decisions have been taken
It is my understanding that we build VPlans and then we determine the cost of each VPlan we have built to find the best VPlan. I haven't had a chance to work in LV for a few months now so I am not so familiar with recent changes. Did we move away from this, or are you describing a different kind of cost decisions?
There was a problem hiding this comment.
Costs are computed first, when building a VPlan they are used to make decision (what to widen, what to scalarize and so on). After building the VPlans, the best VF is chosen using the legacy cost model, but that may soon change.
| @@ -222,6 +222,7 @@ | |||
| # If false, no module index is generated. | |||
| # latex_domain_indices = True | |||
|
|
|||
| numfig = True | |||
There was a problem hiding this comment.
nit: can you add a comment describing the purpose of enabling this?
There was a problem hiding this comment.
Missed originally, should be addressed in 309a881
llvm/docs/VectorizationPlan.rst
Outdated
| introducing active-lane-masks. | ||
| . | ||
| 3. Apply unroll- and vectorization-factor specific optimizations, e.g. removing | ||
| the branch to exit the vector loop based on VF & UF. |
There was a problem hiding this comment.
| the branch to exit the vector loop based on VF & UF. | |
| the backedge to reiterate the vector loop based on VF & UF. |
llvm/docs/VectorizationPlan.rst
Outdated
| 3. Apply unroll- and vectorization-factor specific optimizations, e.g. removing | ||
| the branch to exit the vector loop based on VF & UF. | ||
|
|
||
| Refer to :numref:`fig-vplan-transform-pipeline` for a overview of the current |
There was a problem hiding this comment.
| Refer to :numref:`fig-vplan-transform-pipeline` for a overview of the current | |
| Refer to :numref:`fig-vplan-transform-pipeline` for an overview of the current |
llvm/docs/VectorizationPlan.rst
Outdated
| VPlan Transformation Pipeline in 2024 | ||
|
|
||
|
|
||
| VPlan currently models the complete vector loop, as well as other parts of the |
There was a problem hiding this comment.
| VPlan currently models the complete vector loop, as well as other parts of the | |
| VPlan currently models the complete vector loop, as well as additional parts of the |
| @@ -248,3 +291,6 @@ References | |||
|
|
|||
| .. [9] "Extending LoopVectorizer: OpenMP4.5 SIMD and Outer Loop | |||
| Auto-Vectorization", Intel Vectorizer Team, LLVM Developers' Meeting 2016. | |||
|
|
|||
| .. [10] "VPlan: Status Update and Future Roadmap", Florian Hahn, LLVM | |||
There was a problem hiding this comment.
| .. [10] "VPlan: Status Update and Future Roadmap", Florian Hahn, LLVM | |
| .. [10] "VPlan: Status Update and Future Roadmap", Florian Hahn and Ayal Zaks, LLVM |
There was a problem hiding this comment.
Missed originally, should be addressed in 309a881
|
|
||
| Scope modeled in VPlan in 2024 | ||
|
|
||
|
|
||
| High-level Design | ||
| ================= | ||
|
|
There was a problem hiding this comment.
While we're here, worth also updating the following:
...
:VPInstruction:
A VPInstruction is [both a VPRecipe and a VPUser -> a recipe characterized by a single opcode and optional flags, free of ingredients or other meta-data]. [remove: It models a single
VPlan-level instruction to be generated if the VPlan is executed, including
its opcode and possibly additional characteristics. It is the basis for
writing instruction-level analyses and optimizations in VPlan as creating,
replacing or moving VPInstructions record both def-use and scheduling
decisions.] VPInstructions also extend LLVM IR's opcodes with idiomatic
operations that enrich the Vectorizer's semantics.
BTW, it seems that VPRecipesBase::mayReadFromMemory() and mayWriteToMemory() are missing a case VPInstructionSC:, similar to VPRecipeBase::mayHaveSideEffects()?
...
The Planning Process and VPlan Roadmap
Transforming the Loop Vectorizer to use VPlan follows a staged approach. First,
VPlan [is -> was only] used to record the final vectorization decisions, and to execute them:
the Hierarchical CFG models the planned control-flow, and Recipes capture
decisions taken inside basic-blocks. [Next, VPlan will be -> Currently, VPlan is] used also as the basis
for taking these decisions, effectively turning them into a series of
VPlan-to-VPlan algorithms. Finally, VPlan will support the planning process
itself including cost-based analyses for making these decisions, to fully
support compositional and iterative decision making.
Address comments missed when landing #85689.
Update VectorizationPlan.rst to include a section about the current status of VPlan and its use in LoopVectorize, based on "VPlan: Status Update and Future Roadmap", LLVM Developers’ Meeting 2023, https://www.youtube.com/watch?v=SzGP4PgMuLE
Preview a rendered version here:
https://gist.github.com/fhahn/c4a6d7121b86904ab5e0fdf30ab54940/raw/45bea52de83f4ab500a534d2627d8d6a101cb390/VectorizationPlan-CurrentStatus.pdf