summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPawel Wodnicki <pawel@32bitmicro.com>2012-12-10 14:20:28 +0000
committerPawel Wodnicki <pawel@32bitmicro.com>2012-12-10 14:20:28 +0000
commit3f0b779be8218760033ad0ff698ea88c3c7e73c9 (patch)
tree7855324f577c0b6cc329780ff0feb491303fba63
parent710e1c519ac303c54015c9d8e9f7e28c76f82d41 (diff)
downloadllvm-3f0b779be8218760033ad0ff698ea88c3c7e73c9.tar.gz
llvm-3f0b779be8218760033ad0ff698ea88c3c7e73c9.tar.bz2
llvm-3f0b779be8218760033ad0ff698ea88c3c7e73c9.tar.xz
Merging r169719: into 3.2 release branch.
Fix PR14548: SROA was crashing on a mixture of i1 and i8 loads and stores. When SROA was evaluating a mixture of i1 and i8 loads and stores, in just a particular case, it would tickle a latent bug where we compared bits to bytes rather than bits to bits. As a consequence of the latent bug, we would allow integers through which were not byte-size multiples, a situation the later rewriting code was never intended to handle. In release builds this could trigger all manner of oddities, but the reported issue in PR14548 was forming invalid bitcast instructions. The only downside of this fix is that it makes it more clear that SROA in its current form is not capable of handling mixed i1 and i8 loads and stores. Sometimes with the previous code this would work by luck, but usually it would crash, so I'm not terribly worried. I'll watch the LNT numbers just to be sure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@169735 91177308-0d34-0410-b5e6-96231b3b80d8
-rw-r--r--lib/Transforms/Scalar/SROA.cpp4
-rw-r--r--test/Transforms/SROA/basictest.ll29
-rw-r--r--test/Transforms/SROA/big-endian.ll9
3 files changed, 33 insertions, 9 deletions
diff --git a/lib/Transforms/Scalar/SROA.cpp b/lib/Transforms/Scalar/SROA.cpp
index 062ec05342..2d518f735b 100644
--- a/lib/Transforms/Scalar/SROA.cpp
+++ b/lib/Transforms/Scalar/SROA.cpp
@@ -2201,7 +2201,7 @@ static bool isIntegerWideningViable(const DataLayout &TD,
if (RelBegin == 0 && RelEnd == Size)
WholeAllocaOp = true;
if (IntegerType *ITy = dyn_cast<IntegerType>(LI->getType())) {
- if (ITy->getBitWidth() < TD.getTypeStoreSize(ITy))
+ if (ITy->getBitWidth() < TD.getTypeStoreSizeInBits(ITy))
return false;
continue;
}
@@ -2217,7 +2217,7 @@ static bool isIntegerWideningViable(const DataLayout &TD,
if (RelBegin == 0 && RelEnd == Size)
WholeAllocaOp = true;
if (IntegerType *ITy = dyn_cast<IntegerType>(ValueTy)) {
- if (ITy->getBitWidth() < TD.getTypeStoreSize(ITy))
+ if (ITy->getBitWidth() < TD.getTypeStoreSizeInBits(ITy))
return false;
continue;
}
diff --git a/test/Transforms/SROA/basictest.ll b/test/Transforms/SROA/basictest.ll
index a291c39b33..9fe926ee2c 100644
--- a/test/Transforms/SROA/basictest.ll
+++ b/test/Transforms/SROA/basictest.ll
@@ -1147,3 +1147,32 @@ define void @PR14465() {
ret void
; CHECK: ret
}
+
+define void @PR14548(i1 %x) {
+; Handle a mixture of i1 and i8 loads and stores to allocas. This particular
+; pattern caused crashes and invalid output in the PR, and its nature will
+; trigger a mixture in several permutations as we resolve each alloca
+; iteratively.
+; Note that we don't do a particularly good *job* of handling these mixtures,
+; but the hope is that this is very rare.
+; CHECK: @PR14548
+
+entry:
+ %a = alloca <{ i1 }>, align 8
+ %b = alloca <{ i1 }>, align 8
+; Nothing of interest is simplified here.
+; CHECK: alloca
+; CHECK: alloca
+
+ %b.i1 = bitcast <{ i1 }>* %b to i1*
+ store i1 %x, i1* %b.i1, align 8
+ %b.i8 = bitcast <{ i1 }>* %b to i8*
+ %foo = load i8* %b.i8, align 1
+
+ %a.i8 = bitcast <{ i1 }>* %a to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %a.i8, i8* %b.i8, i32 1, i32 1, i1 false) nounwind
+ %bar = load i8* %a.i8, align 1
+ %a.i1 = getelementptr inbounds <{ i1 }>* %a, i32 0, i32 0
+ %baz = load i1* %a.i1, align 1
+ ret void
+}
diff --git a/test/Transforms/SROA/big-endian.ll b/test/Transforms/SROA/big-endian.ll
index ce82d1f30b..1ac6d25d63 100644
--- a/test/Transforms/SROA/big-endian.ll
+++ b/test/Transforms/SROA/big-endian.ll
@@ -82,14 +82,9 @@ entry:
%a0i16ptr = bitcast i8* %a0ptr to i16*
store i16 1, i16* %a0i16ptr
-; CHECK: %[[mask0:.*]] = and i16 1, -16
-
- %a1i4ptr = bitcast i8* %a1ptr to i4*
- store i4 1, i4* %a1i4ptr
-; CHECK-NEXT: %[[insert0:.*]] = or i16 %[[mask0]], 1
store i8 1, i8* %a2ptr
-; CHECK-NEXT: %[[mask1:.*]] = and i40 undef, 4294967295
+; CHECK: %[[mask1:.*]] = and i40 undef, 4294967295
; CHECK-NEXT: %[[insert1:.*]] = or i40 %[[mask1]], 4294967296
%a3i24ptr = bitcast i8* %a3ptr to i24*
@@ -110,7 +105,7 @@ entry:
%ai = load i56* %aiptr
%ret = zext i56 %ai to i64
ret i64 %ret
-; CHECK-NEXT: %[[ext4:.*]] = zext i16 %[[insert0]] to i56
+; CHECK-NEXT: %[[ext4:.*]] = zext i16 1 to i56
; CHECK-NEXT: %[[shift4:.*]] = shl i56 %[[ext4]], 40
; CHECK-NEXT: %[[mask4:.*]] = and i56 %[[insert3]], 1099511627775
; CHECK-NEXT: %[[insert4:.*]] = or i56 %[[mask4]], %[[shift4]]