[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