[PATCH] D154714: LAA: handle GEPs with >2 operands in findForkedSCEVs()
Ramkumar Ramachandra via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 7 07:58:04 PDT 2023
artagnon added inline comments.
================
Comment at: llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll:987
+ %1 = or i64 %indvars.iv, 1
+ %arrayidx = getelementptr inbounds [2048 x i8], ptr %0, i64 0, i64 %indvars.iv
+ store i8 3, ptr %arrayidx
----------------
fhahn wrote:
> I'm not sure if/how this fits into the forked pointer handling. The forked pointer handling is to support cases where a GEP can have multiple base pointers (e.g. due to a select or phi). But in this case there are 2 distinct GEPs each with their separate base pointer.
I saw the comment on top of `findForkedPointers()`, and was initially confused too, but I think `findForkedPointers()` can be extended to support the use-case at hand: yes, there are two distinct GEPs, with separate base pointers, but really, both of them are loading the same ptr with different offsets: I look inside the load to find the SCEV associated to `@ld`, and the case at hand does seem to be vectorized successfully. Is the vectorization of the test-case I've provided incorrect?
If I weren't to modify `findForkedPointers()`, I'm left with SCEV AddExprs, which I have no idea how to handle independently of each other, and vectorization bails out saying that the expressions are not AddRecs.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154714/new/
https://reviews.llvm.org/D154714
More information about the llvm-commits
mailing list