Add some comments clarifying that the GEP analysis for vector GEPs is

deeply suspicious and likely to go away eventually. Also fix a bogus
comment about one of the checks in the vector GEP analysis. Based on
review from Duncan.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163894 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/lib/Transforms/Scalar/SROA.cpp b/lib/Transforms/Scalar/SROA.cpp
index acfa87a32ebf51861314ebcaf705511a434867f1..97c28d442ad3899286bdffe954d64cffd6f88812 100644 (file)
--- a/lib/Transforms/Scalar/SROA.cpp
+++ b/lib/Transforms/Scalar/SROA.cpp
@@ -1300,10 +1300,13 @@ static Value *getNaturalGEPRecursively(IRBuilder<> &IRB, const TargetData &TD,
   if (Ty->isPointerTy())
     return 0;
 
+  // We try to analyze GEPs over vectors here, but note that these GEPs are
+  // extremely poorly defined currently. The long-term goal is to remove GEPing
+  // over a vector from the IR completely.
   if (VectorType *VecTy = dyn_cast<VectorType>(Ty)) {
     unsigned ElementSizeInBits = VecTy->getScalarSizeInBits();
     if (ElementSizeInBits % 8)
-      return 0; // GEPs over multiple of 8 size vector elements are invalid.
+      return 0; // GEPs over non-multiple of 8 size vector elements are invalid.
     APInt ElementSize(Offset.getBitWidth(), ElementSizeInBits / 8);
     APInt NumSkippedElements = Offset.udiv(ElementSize);
     if (NumSkippedElements.ugt(VecTy->getNumElements()))