Introduce LoopVectorizationPlanner.executePlan(), replacing ILV.vectorize() and refactoring ILV.vectorizeLoop(). collectDeadInstructions() is moved from ILV to LVP.
These will facilitate building VPlans and using them to generate code, following https://reviews.llvm.org/D28975 and its tentative breakdown.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
395 ↗ | (On Diff #95643) | I see what you mean, but I also don't have any real suggestions. Something like LV.vectorizeLoop(LVP.getBestVPlan()) might be more straightforward than LVP.executePlan(). But I'm not sure how such a change would affect the refactoring plans. |
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
472 ↗ | (On Diff #95643) | Sure, will do. |
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
395 ↗ | (On Diff #95643) | ILV.createEmptyLoop() should indeed better be renamed ILV.createVectorizedLoop(). The refactoring plans aim to employ ILV for code-generation services, such as vectorizeInstruction(), driven by VPlan.transform() via its Recipes. Similarly to later employing CM for cost-model services by VPlan.expectedCost(), thereby aligning the two. Invoking VPlan.transform() on the best VPlan should eventually take care of all code generation. Before having VPlan in place, covering all code generation, this patch proposes to have LVP.executePlan() take care of it. collectTriviallyDeadInstructions() is moved to LVP, and will later serve it to construct VPlans; in this patch it serves LVP to generate the code. |
Hi Ayal,
I like where this is going, particularly the executePlan idiom. I don't think it's a really big deal now how we organise the interface, given that it's going to change (probably radically) once VPlans start to trickle in.
A few silly comments on comments, but otherwise, it's looking good. Thanks!
I'll let @mssimpso and @mkuper finish their reviews. :)
cheers,
--renato
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
394 ↗ | (On Diff #96370) | This also vectorises, no? This comment implies it just replaces with an empty loop. |
7531 ↗ | (On Diff #96370) | This is not strictly true, as it could be unrolling, right? Maybe you should say "loop transformation"? |
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
394 ↗ | (On Diff #96370) | Ahh, no, it creates an empty loop into which vector code will subsequently be inserted (by calls to vectorizeInstruction()), and introduces its scalar induction variable of step VF*UF. It also creates all the surrounding blocks, branches, etc.. This was the exact original behavior of the method, and its original comment. This patch only exposes it publicly, to be (re)used for generating code by vplan. Perhaps a better yet name for it may be createVectorizedLoopSkeleton(). Can we agree on this, or other welcomed suggestions? |
7531 ↗ | (On Diff #96370) | Right, executing a Plan follows the selected VF and UF, which may end up producing vector and/or unrolled code. This is the original comment taken from ILV::vectorize(), which also serves the Unroller. Agreed, we should say "loop transformation" instead. |
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
394 ↗ | (On Diff #96370) | Right, I see. I'm ok with whatever name that reflects that this is just the new empty loop. Not all TAB-completion bring the comments above the function. :) |
Ping.
https://reviews.llvm.org/D32871 includes an updated version of this patch. It will be updated once this patch is approved and committed.
Hey Ayal,
Sorry to lose track of this patch. It looks good to me.
lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
7880 ↗ | (On Diff #96370) | Do we know how this ended up begin "LB"? We might should change it to something more meaningful at some point (not in this patch, though). |