[PATCH] D102834: [SLPVectorizer] Implement initial memory versioning.

Sjoerd Meijer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 3 08:50:14 PDT 2021


SjoerdMeijer added a comment.

I have now read the code for the first time, and here's a first round of comments.
I definitely need to read this again, which is what I will do soon...



================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:189
+static cl::opt<bool> EnableMemoryVersioning(
+    "slp-memory-versioning", cl::init(false), cl::Hidden,
+    cl::desc("Enable memory versioning for SLP vectorization."));
----------------
This is a nitpick, bikeshedding names... but I was wondering about the terminology here (i.e. memory versioning).
We emit runtime memory checks, and do versioning of a block. So was wondering if this should be BlockVersioning. 


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6999
+              if (!DestBundle->IsScheduled && SLP->CollectMemAccess) {
+                // FIXME Naming
+                auto GetPtr = [](Instruction *I) -> Value * {
----------------
Remove this?


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:7611
+    Tail = SplitBlock(BB, LastTrackedInst->getNextNode(), &DTU, LI, nullptr,
+                      OriginalBBName + ".tail");
+  auto *CheckBlock = BB;
----------------
Don't think I have seen a block name with the .tail suffix in the tests.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:7647
+
+  // Add !noalias metadata to memory accesses in the versiond block.
+  LLVMContext &Ctx = BB->getContext();
----------------
typo: versiond -> versioned.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:7650
+  MDBuilder MDB(Ctx);
+  MDNode *Domain = MDB.createAnonymousAliasScopeDomain("SLPVerDomain");
+
----------------
I am not that familiar with this, but do we expect this in one of the tests?


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:7735
+  SLPCost += 5 * PointerChecks.size() + MemBounds.size();
+  if (SLPCost >= ScalarCost) {
+    // Vectorization not beneficial or possible. Restore original state by
----------------
Perhaps create a local helper function to handle this case.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:7736
+  if (SLPCost >= ScalarCost) {
+    // Vectorization not beneficial or possible. Restore original state by
+    // removing the introduced blocks.
----------------
Re: "or possible", I would guess it's possible but not profitable?


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:7763
+    NumVersioningFailed++;
+  } else {
+    R.getORE()->emit(
----------------
And another helper for this case too.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6843
 
-bool SLPVectorizerPass::runImpl(Function &F, ScalarEvolution *SE_,
-                                TargetTransformInfo *TTI_,
-                                TargetLibraryInfo *TLI_, AAResults *AA_,
-                                LoopInfo *LI_, DominatorTree *DT_,
-                                AssumptionCache *AC_, DemandedBits *DB_,
-                                OptimizationRemarkEmitter *ORE_) {
+SLPVectorizerResult SLPVectorizerPass::vectorizeBlockWithVersioning(
+    BasicBlock *BB, const SmallPtrSetImpl<Value *> &TrackedObjects,
----------------
Somewhere a high-level idea and description of the algorithm would be nice, I guess that would be here.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6850
+
+  // First, clean up delete instructions, so they are not re-used during SCEV
+  // expansion.
----------------
Typo? delete -> deleted.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6870
+
+    unsigned AS = Obj->getType()->getPointerAddressSpace();
+
----------------
Unused?


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6872
+
+    // We know that the Start is dereferenced, hence adding one should not
+    // overflow: https://alive2.llvm.org/ce/z/dTuGLx
----------------
That wasn't obvious to me, why is Start dereferenced?


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6873
+    // We know that the Start is dereferenced, hence adding one should not
+    // overflow: https://alive2.llvm.org/ce/z/dTuGLx
+    auto &DL = BB->getModule()->getDataLayout();
----------------
Do we want to link to alive (not sure how persistent the data is and if it's common), or just expand the example here?


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6900
+    return all_of(make_range(FirstTrackedInst->getIterator(),
+                             std::next(LastTrackedInst->getIterator())),
+                  [LastTrackedInst, BB](Instruction &I) {
----------------
Could `std::next` return null (or end)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102834/new/

https://reviews.llvm.org/D102834



More information about the llvm-commits mailing list