Fix PR14212: For some strange reason I treated vectors differently from

integers in that the code to handle split alloca-wide integer loads or
stores doesn't come first. It should, for the same reasons as with
integers, and the PR attests to that. Also had to fix a busted assert in
that this test case also covers.

llvm-svn: 167051

2 files changed, 18 insertions, 4 deletions

diff --git a/llvm/lib/Transforms/Scalar/SROA.cpp b/llvm/lib/Transforms/Scalar/SROA.cpp
index af3a880cb90..1d0ba1c2c16 100644
--- a/llvm/lib/Transforms/Scalar/SROA.cpp
+++ b/llvm/lib/Transforms/Scalar/SROA.cpp
@@ -2490,9 +2490,6 @@ private:
     assert(OldOp == OldPtr);
     IRBuilder<> IRB(&LI);
 
-    if (VecTy)
-      return rewriteVectorizedLoadInst(IRB, LI, OldOp);
-
     uint64_t Size = EndOffset - BeginOffset;
     if (Size < TD.getTypeStoreSize(LI.getType())) {
       assert(!LI.isVolatile());
@@ -2502,7 +2499,7 @@ private:
              TD.getTypeStoreSizeInBits(LI.getType()) &&
              "Non-byte-multiple bit width");
       assert(LI.getType()->getIntegerBitWidth() ==
-             TD.getTypeSizeInBits(OldAI.getAllocatedType()) &&
+             TD.getTypeAllocSizeInBits(OldAI.getAllocatedType()) &&
              "Only alloca-wide loads can be split and recomposed");
       IntegerType *NarrowTy = Type::getIntNTy(LI.getContext(), Size * 8);
       bool IsConvertable = (BeginOffset - NewAllocaBeginOffset == 0) &&
@@ -2536,6 +2533,8 @@ private:
       return IsConvertable;
     }
 
+    if (VecTy)
+      return rewriteVectorizedLoadInst(IRB, LI, OldOp);
     if (IntTy && LI.getType()->isIntegerTy())
       return rewriteIntegerLoad(IRB, LI);
 
diff --git a/llvm/test/Transforms/SROA/vector-promotion.ll b/llvm/test/Transforms/SROA/vector-promotion.ll
index 92051c62a7c..02e084bf112 100644
--- a/llvm/test/Transforms/SROA/vector-promotion.ll
+++ b/llvm/test/Transforms/SROA/vector-promotion.ll
@@ -205,3 +205,18 @@ define i64 @test6(<4 x i64> %x, <4 x i64> %y, i64 %n) {
   %res = load i64* %addr, align 4
   ret i64 %res
 }
+
+define i32 @PR14212() {
+; CHECK: @PR14212
+; This caused a crash when "splitting" the load of the i32 in order to promote
+; the store of <3 x i8> properly. Heavily reduced from an OpenCL test case.
+entry:
+  %retval = alloca <3 x i8>, align 4
+; CHECK-NOT: alloca
+
+  store <3 x i8> undef, <3 x i8>* %retval, align 4
+  %cast = bitcast <3 x i8>* %retval to i32*
+  %load = load i32* %cast, align 4
+  ret i32 %load
+; CHECK: ret i32
+}