[PATCH] D24271: [LV] Don't mark pointers used by scalarized memory accesses uniform

Michael Kuperstein via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 7 10:56:04 PDT 2016


mkuper added inline comments.

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:5326
@@ +5325,3 @@
+  StoreInst *SI = dyn_cast<StoreInst>(I);
+  assert((LI || SI) && "Invalid memory instruction");
+
----------------
What I meant was that I would have preferred a single shared function that performs all of these checks, so that it's easier to keep memoryInstructionMayBeScalarized and vectorizeMemoryInstruction in sync. 
(I didn't notice the VF issue, but you could pass VF as part of the interface to that shared helper).

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:5332-5334
@@ +5331,5 @@
+    return true;
+
+  // If the instruction's allocated type size doesn't equal it's stored type
+  // size, it requires padding and may be scalarized.
+  auto &DL = I->getModule()->getDataLayout();
----------------
I think in vectorizeMemoryInstruction you really want VF.

Let's say you have i20, and the ABI alignment for i20 is 1 byte.
Assuming I didn't get the math wrong:
For scalars, you'll have ScalarAllocatedSize == VectorElementSize == 3, so the type is regular.
But for VF=4, you'll DL.getTypeStoreSize(VectorTy) == 10, so VectorElementSize ==2, and the type is irregular.

Which is exactly what we want to happen - storing 4 consecutive i20s writes 12 bytes, not 10, so we can't vectorize the store.

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:5337
@@ +5336,3 @@
+  auto *ScalarDataTy = LI ? LI->getType() : SI->getValueOperand()->getType();
+  if (hasIrregularType(ScalarDataTy, DL))
+    return true;
----------------
Now that I thought about this a bit more, checking this with "1" is probably not very useful. Maybe 2? (since, as discussed above, we don't have the final VF). Although I'm not 100% sure 2 makes sense either.


https://reviews.llvm.org/D24271





More information about the llvm-commits mailing list