[PATCH] D65600: Relax load store vectorizer pointer strip checks

Artem Belevich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 1 13:42:14 PDT 2019


tra added a comment.

It looks to me that the root cause is in



================
Comment at: lib/Transforms/Vectorize/LoadStoreVectorizer.cpp:347-348
 
-  if (PtrA->getType()->getPointerAddressSpace() != PtrAS ||
-      PtrB->getType()->getPointerAddressSpace() != PtrAS)
+  if (DL.getTypeStoreSizeInBits(PtrA->getType()) != PtrBitWidth ||
+      DL.getTypeStoreSizeInBits(PtrB->getType()) != PtrBitWidth)
     return false;
----------------
If we were to use addrspacecast(1) instead of 5 in the example below, we'd proceed with the checks.
If we can deal with non-generic address spaces in principle, why can't we deal with address spaces that differ in pointer size? I'd assume that logic that determines consecutiveness should work the same.

I guess one way to handle mismatched address spaces would be to normalize the pointer to the common address space (generic?) and then run the checks for the consecutiveness.




================
Comment at: test/Transforms/LoadStoreVectorizer/AMDGPU/vect-ptr-ptr-size-mismatch.ll:3
 
-target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32"
+target datalayout = "e-p:64:64-p1:64:64-p5:32:32"
 
----------------
It would be good to add a comment that p5:32:32 is the critical part here as that's what causes the original problem.


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

https://reviews.llvm.org/D65600





More information about the llvm-commits mailing list