This patch turns updates VPInterleaveRecipe to manage the values it defines
using VPDef. The VPValue is used during VPlan construction and
codegeneration instead of the plain IR reference where possible.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8387 | Could you elaborate on why applying the interleave groups is moved back to VPlan creation? |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8387 | The current handling (create recipes for each instruction and remove & replace them with a single interleave recipe later) seems like a work-around and now that we can manage the VPValues for the members of the interleave groups directly, I think it makes sense to directly create them along with the other recipes. Unfortunately this requires a bit more extra logic to skip interleave groups members when recording the sink-after points, which is not great. But I think this will go away in the future, if we start by building an initial VPlan and gradually lower to specialized recipes. But I can also keep the VPInterleaveRecipe creation at the original position, if you prefer. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8387 |
Right. This dependence between sink-after and interleave groups which translates to careful bookkeeping is why LV applies them as ordered VPlan-VPlan transformations. Ayal presented this change at the 2017 Dev. Meeting as a motivating example for the general direction of an initial trivial VPlan gradually & immediately transformed as decisions are taken, replacing LV's decision-recording maps which make it difficult to compose decisions. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8387 | I have a few patches to get us roughly there and D90712 applies sink-after before lowering to specialized recipes, which makes the recording of recipes redundant. So my preference would be to keep thing as-is in the current patch. But as I said I am more than happy to update the patch to do it the 'old' way for now if you think that's preferable. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8387 |
I think so, to avoid the bookkeeping and keep the patch's scope minimal. |
Thanks Gil! I restored the original code for creating/inserting VPInterleaveRecipe, to reduce diff.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8387 | Done, its much cleaner now :) |
This commit is causing the following
int example(int n, int *arr) { int ret = 0; for( int i = 0; i < n; i += 2 ) { ret = arr[i+1] + arr[i] + ret; } return ret; }
to hit an assertion failure when compiled with --target=arm-none-eabi -march=armv8.1-m.main+mve -O2:
llvm-project/llvm/lib/Transforms/Vectorize/VPlan.h:1770: llvm::VPValue* llvm::VPlan::getVPValue(llvm::Value*): Assertion `Value2VPValue.count(V) && "Value does not exist in VPlan"' failed.
with the backtrace showing that the assert was hit in llvm::LoopVectorizationPlanner::adjustRecipesForInLoopReductions.
Could you elaborate on why applying the interleave groups is moved back to VPlan creation?