[PATCH] D20789: Consecutive memory access in Loop Vectorizer - fixed and simplified
Adam Nemet via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 7 09:04:00 PDT 2016
anemet added inline comments.
================
Comment at: ../lib/Analysis/LoopAccessAnalysis.cpp:913-917
@@ -861,1 +912,7 @@
+ if (!AR)
+ // One more attempt to get stride from GEP with index calculated in runtime
+ if (auto *Gep = dyn_cast<GetElementPtrInst>(Ptr))
+ if (int Stride = getConsecutiveAccessFromGEPIndex(PSE, Gep, Lp, StridesMap))
+ return Stride;
+
----------------
delena wrote:
> anemet wrote:
> > Sorry for jumping in late but I was on vacation. Elena, does your testcase actually exercise this part of the code or it's handled as a regular AddRec above? I am assuming not since the Ptr is not a GEP.
> >
> > Do we actually have coverage exercising this part?
> >
> The test that exercises this code is in version-mem-access.ll. This is the existing test that fails without this extension.
> My test case does not have GEP (but it has AddRec ) and this case wan't handled properly.
OK and what is the SCEV that fails to become an AddRec after replaceSymbolicStrideSCEV?
I am wondering if there is a fundamental reason we need getConsecutiveAccessFromGEPIndex. My guess is that it's this in getConsecutiveAccessFromGEPIndex:
// Because of the multiplication by a stride we can have a s/zext cast.
// We are going to replace this stride by 1 so the cast is safe to ignore.
which does not seem fundamental.
Repository:
rL LLVM
http://reviews.llvm.org/D20789
More information about the llvm-commits
mailing list