[llvm] [VPlan] Extract reverse operation for reverse accesses (PR #146525)
Luke Lau via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 24 06:57:39 PST 2025
================
@@ -2625,6 +2648,34 @@ static void transformRecipestoEVLRecipes(VPlan &Plan, VPValue &EVL) {
}
}
ToErase.push_back(CurRecipe);
+
+ // Convert general reverse operations on loaded results into vp.reverse,
+ // when the VPVectorEndPointerRecipe adjusting the access address uses EVL
+ // instead of VF.
+ if (auto *LoadR = dyn_cast<VPWidenLoadEVLRecipe>(EVLRecipe)) {
----------------
lukel97 wrote:
I took some time to try this out locally and I understand what you mean, I ran into issue 1) where folding away the reverse prevents us from forming a VP intrinsic.
I think the root of the problem is that the optimziation we're doing isn't general enough, i.e. for a load we don't actually need it to be reversed. What I think long term is that we need to define them in terms of slides, e.g:
```
load(vec-end-ptr(ptr, vf), mask=reverse(prefix-mask))
= ..abcdef
-->
slideup(vp.load(vec-end-ptr(ptr, evl), evl), vf-evl)
= slideup(abcdef.., vf-evl)
= ..abcdef
```
Stores would conversely have a slidedown. If a pair of reverses are eliminated then we would be left with a pair of slide ups and slide downs, which can also be eliminated.
We can almost do the slide with the splice intrinsic but unfortunately it's restricted to immediate offsets at the moment.
These are just my long-term thoughts btw, I don't think this should block this PR.
https://github.com/llvm/llvm-project/pull/146525
More information about the llvm-commits
mailing list