[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