|
| 1 | +; RUN: opt -bdce %s -S | FileCheck %s |
| 2 | + |
| 3 | +; The 'nuw' on the subtract allows us to deduce that %setbit is not demanded. |
| 4 | +; But if we change that value to '0', then the 'nuw' is no longer valid. If we don't |
| 5 | +; remove the 'nuw', another pass (-instcombine) may make a transform based on an |
| 6 | +; that incorrect assumption and we can miscompile: |
| 7 | +; https://bugs.llvm.org/show_bug.cgi?id=33695 |
| 8 | + |
| 9 | +define i1 @PR33695(i1 %b, i8 %x) { |
| 10 | +; CHECK-LABEL: @PR33695( |
| 11 | +; CHECK-NEXT: [[SETBIT:%.*]] = or i8 %x, 64 |
| 12 | +; CHECK-NEXT: [[LITTLE_NUMBER:%.*]] = zext i1 %b to i8 |
| 13 | +; CHECK-NEXT: [[BIG_NUMBER:%.*]] = shl i8 0, 1 |
| 14 | +; CHECK-NEXT: [[SUB:%.*]] = sub i8 [[BIG_NUMBER]], [[LITTLE_NUMBER]] |
| 15 | +; CHECK-NEXT: [[TRUNC:%.*]] = trunc i8 [[SUB]] to i1 |
| 16 | +; CHECK-NEXT: ret i1 [[TRUNC]] |
| 17 | +; |
| 18 | + %setbit = or i8 %x, 64 |
| 19 | + %little_number = zext i1 %b to i8 |
| 20 | + %big_number = shl i8 %setbit, 1 |
| 21 | + %sub = sub nuw i8 %big_number, %little_number |
| 22 | + %trunc = trunc i8 %sub to i1 |
| 23 | + ret i1 %trunc |
| 24 | +} |
| 25 | + |
| 26 | +; Similar to above, but now with more no-wrap. |
| 27 | +; https://bugs.llvm.org/show_bug.cgi?id=34037 |
| 28 | + |
| 29 | +define i64 @PR34037(i64 %m, i32 %r, i64 %j, i1 %b, i32 %k, i64 %p) { |
| 30 | +; CHECK-LABEL: @PR34037( |
| 31 | +; CHECK-NEXT: [[CONV:%.*]] = zext i32 %r to i64 |
| 32 | +; CHECK-NEXT: [[AND:%.*]] = and i64 %m, 0 |
| 33 | +; CHECK-NEXT: [[NEG:%.*]] = xor i64 0, 34359738367 |
| 34 | +; CHECK-NEXT: [[OR:%.*]] = or i64 %j, 0 |
| 35 | +; CHECK-NEXT: [[SHL:%.*]] = shl i64 0, 29 |
| 36 | +; CHECK-NEXT: [[CONV1:%.*]] = select i1 %b, i64 7, i64 0 |
| 37 | +; CHECK-NEXT: [[SUB:%.*]] = sub i64 [[SHL]], [[CONV1]] |
| 38 | +; CHECK-NEXT: [[CONV2:%.*]] = zext i32 %k to i64 |
| 39 | +; CHECK-NEXT: [[MUL:%.*]] = mul i64 [[SUB]], [[CONV2]] |
| 40 | +; CHECK-NEXT: [[CONV4:%.*]] = and i64 %p, 65535 |
| 41 | +; CHECK-NEXT: [[AND5:%.*]] = and i64 [[MUL]], [[CONV4]] |
| 42 | +; CHECK-NEXT: ret i64 [[AND5]] |
| 43 | +; |
| 44 | + %conv = zext i32 %r to i64 |
| 45 | + %and = and i64 %m, %conv |
| 46 | + %neg = xor i64 %and, 34359738367 |
| 47 | + %or = or i64 %j, %neg |
| 48 | + %shl = shl i64 %or, 29 |
| 49 | + %conv1 = select i1 %b, i64 7, i64 0 |
| 50 | + %sub = sub nuw nsw i64 %shl, %conv1 |
| 51 | + %conv2 = zext i32 %k to i64 |
| 52 | + %mul = mul nsw i64 %sub, %conv2 |
| 53 | + %conv4 = and i64 %p, 65535 |
| 54 | + %and5 = and i64 %mul, %conv4 |
| 55 | + ret i64 %and5 |
| 56 | +} |
| 57 | + |
| 58 | +; This is a manufactured example based on the 1st test to prove that the |
| 59 | +; assumption-killing algorithm stops at the call. Ie, it does not remove |
| 60 | +; nsw/nuw from the 'add' because a call demands all bits of its argument. |
| 61 | + |
| 62 | +declare i1 @foo(i1) |
| 63 | + |
| 64 | +define i1 @poison_on_call_user_is_ok(i1 %b, i8 %x) { |
| 65 | +; CHECK-LABEL: @poison_on_call_user_is_ok( |
| 66 | +; CHECK-NEXT: [[SETBIT:%.*]] = or i8 %x, 64 |
| 67 | +; CHECK-NEXT: [[LITTLE_NUMBER:%.*]] = zext i1 %b to i8 |
| 68 | +; CHECK-NEXT: [[BIG_NUMBER:%.*]] = shl i8 0, 1 |
| 69 | +; CHECK-NEXT: [[SUB:%.*]] = sub i8 [[BIG_NUMBER]], [[LITTLE_NUMBER]] |
| 70 | +; CHECK-NEXT: [[TRUNC:%.*]] = trunc i8 [[SUB]] to i1 |
| 71 | +; CHECK-NEXT: [[CALL_RESULT:%.*]] = call i1 @foo(i1 [[TRUNC]]) |
| 72 | +; CHECK-NEXT: [[ADD:%.*]] = add nuw nsw i1 [[CALL_RESULT]], true |
| 73 | +; CHECK-NEXT: [[MUL:%.*]] = mul i1 [[TRUNC]], [[ADD]] |
| 74 | +; CHECK-NEXT: ret i1 [[MUL]] |
| 75 | +; |
| 76 | + %setbit = or i8 %x, 64 |
| 77 | + %little_number = zext i1 %b to i8 |
| 78 | + %big_number = shl i8 %setbit, 1 |
| 79 | + %sub = sub nuw i8 %big_number, %little_number |
| 80 | + %trunc = trunc i8 %sub to i1 |
| 81 | + %call_result = call i1 @foo(i1 %trunc) |
| 82 | + %add = add nsw nuw i1 %call_result, 1 |
| 83 | + %mul = mul i1 %trunc, %add |
| 84 | + ret i1 %mul |
| 85 | +} |
| 86 | + |
| 87 | + |
| 88 | +; We were asserting that all users of a trivialized integer-type instruction were |
| 89 | +; also integer-typed, but that's too strong. The alloca has a pointer-type result. |
| 90 | + |
| 91 | +define void @PR34179(i32* %a) { |
| 92 | +; CHECK-LABEL: @PR34179( |
| 93 | +; CHECK-NEXT: [[T0:%.*]] = load volatile i32, i32* %a |
| 94 | +; CHECK-NEXT: ret void |
| 95 | +; |
| 96 | + %t0 = load volatile i32, i32* %a |
| 97 | + %vla = alloca i32, i32 %t0 |
| 98 | + ret void |
| 99 | +} |
| 100 | + |
0 commit comments