llvm.org GIT mirror llvm / 3f0b779
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 Pawel Wodnicki 6 years ago
3 changed file(s) with 33 addition(s) and 9 deletion(s). Raw diff Collapse all Expand all
22002200 if (RelBegin == 0 && RelEnd == Size)
22012201 WholeAllocaOp = true;
22022202 if (IntegerType *ITy = dyn_cast(LI->getType())) {
2203 if (ITy->getBitWidth() < TD.getTypeStoreSize(ITy))
2203 if (ITy->getBitWidth() < TD.getTypeStoreSizeInBits(ITy))
22042204 return false;
22052205 continue;
22062206 }
22162216 if (RelBegin == 0 && RelEnd == Size)
22172217 WholeAllocaOp = true;
22182218 if (IntegerType *ITy = dyn_cast(ValueTy)) {
2219 if (ITy->getBitWidth() < TD.getTypeStoreSize(ITy))
2219 if (ITy->getBitWidth() < TD.getTypeStoreSizeInBits(ITy))
22202220 return false;
22212221 continue;
22222222 }
11461146 ret void
11471147 ; CHECK: ret
11481148 }
1149
1150 define void @PR14548(i1 %x) {
1151 ; Handle a mixture of i1 and i8 loads and stores to allocas. This particular
1152 ; pattern caused crashes and invalid output in the PR, and its nature will
1153 ; trigger a mixture in several permutations as we resolve each alloca
1154 ; iteratively.
1155 ; Note that we don't do a particularly good *job* of handling these mixtures,
1156 ; but the hope is that this is very rare.
1157 ; CHECK: @PR14548
1158
1159 entry:
1160 %a = alloca <{ i1 }>, align 8
1161 %b = alloca <{ i1 }>, align 8
1162 ; Nothing of interest is simplified here.
1163 ; CHECK: alloca
1164 ; CHECK: alloca
1165
1166 %b.i1 = bitcast <{ i1 }>* %b to i1*
1167 store i1 %x, i1* %b.i1, align 8
1168 %b.i8 = bitcast <{ i1 }>* %b to i8*
1169 %foo = load i8* %b.i8, align 1
1170
1171 %a.i8 = bitcast <{ i1 }>* %a to i8*
1172 call void @llvm.memcpy.p0i8.p0i8.i32(i8* %a.i8, i8* %b.i8, i32 1, i32 1, i1 false) nounwind
1173 %bar = load i8* %a.i8, align 1
1174 %a.i1 = getelementptr inbounds <{ i1 }>* %a, i32 0, i32 0
1175 %baz = load i1* %a.i1, align 1
1176 ret void
1177 }
8181
8282 %a0i16ptr = bitcast i8* %a0ptr to i16*
8383 store i16 1, i16* %a0i16ptr
84 ; CHECK: %[[mask0:.*]] = and i16 1, -16
85
86 %a1i4ptr = bitcast i8* %a1ptr to i4*
87 store i4 1, i4* %a1i4ptr
88 ; CHECK-NEXT: %[[insert0:.*]] = or i16 %[[mask0]], 1
8984
9085 store i8 1, i8* %a2ptr
91 ; CHECK-NEXT: %[[mask1:.*]] = and i40 undef, 4294967295
86 ; CHECK: %[[mask1:.*]] = and i40 undef, 4294967295
9287 ; CHECK-NEXT: %[[insert1:.*]] = or i40 %[[mask1]], 4294967296
9388
9489 %a3i24ptr = bitcast i8* %a3ptr to i24*
109104 %ai = load i56* %aiptr
110105 %ret = zext i56 %ai to i64
111106 ret i64 %ret
112 ; CHECK-NEXT: %[[ext4:.*]] = zext i16 %[[insert0]] to i56
107 ; CHECK-NEXT: %[[ext4:.*]] = zext i16 1 to i56
113108 ; CHECK-NEXT: %[[shift4:.*]] = shl i56 %[[ext4]], 40
114109 ; CHECK-NEXT: %[[mask4:.*]] = and i56 %[[insert3]], 1099511627775
115110 ; CHECK-NEXT: %[[insert4:.*]] = or i56 %[[mask4]], %[[shift4]]