1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152
|
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt -S -guard-widening -dce < %s | FileCheck %s
; FIXME: All the tests below must be fixed.
declare void @llvm.experimental.guard(i1,...)
; This tests shows the incorrect behavior of guard widening in terms of
; interaction with poison values.
; Let x incoming parameter is used for rane checks.
; Test generates 5 checks. One of them (c2) is used to get the corretness
; of nuw/nsw flags for x3 and x5. Others are used in guards and represent
; the checks x + 10 u< L, x + 15 u< L, x + 20 u< L and x + 3 u< L.
; The first two checks are in the first basic block and guard widening
; considers them as profitable to combine.
; When c4 and c3 are considered, number of check becomes more than two
; and combineRangeCheck consider them as profitable even if they are in
; different basic blocks.
; Accoding to algorithm of combineRangeCheck it detects that c3 and c4
; are enough to cover c1 and c5, so it ends up with guard of c3 && c4
; while both of them are poison at entry. This is a bug.
define void @combine_range_checks(i32 %x) {
; CHECK-LABEL: @combine_range_checks(
; CHECK-NEXT: entry:
; CHECK-NEXT: [[X2:%.*]] = add i32 [[X:%.*]], 0
; CHECK-NEXT: [[C2:%.*]] = icmp ult i32 [[X2]], 200
; CHECK-NEXT: [[X3:%.*]] = add nuw nsw i32 [[X]], 3
; CHECK-NEXT: [[C3:%.*]] = icmp ult i32 [[X3]], 100
; CHECK-NEXT: [[X4:%.*]] = add nuw nsw i32 [[X]], 20
; CHECK-NEXT: [[C4:%.*]] = icmp ult i32 [[X4]], 100
; CHECK-NEXT: [[WIDE_CHK2:%.*]] = and i1 [[C4]], [[C3]]
; CHECK-NEXT: call void (i1, ...) @llvm.experimental.guard(i1 [[WIDE_CHK2]]) [ "deopt"(i64 1) ]
; CHECK-NEXT: br i1 [[C2]], label [[OK:%.*]], label [[OUT:%.*]]
; CHECK: ok:
; CHECK-NEXT: br label [[OUT]]
; CHECK: out:
; CHECK-NEXT: ret void
;
entry:
%x1 = add i32 %x, 10
%c1 = icmp ult i32 %x1, 100
%x2 = add i32 %x, 0
%c2 = icmp ult i32 %x2, 200
%x3 = add nuw nsw i32 %x, 3
%c3 = icmp ult i32 %x3, 100
%x4 = add nuw nsw i32 %x, 20
%c4 = icmp ult i32 %x4, 100
%x5 = add i32 %x, 15
%c5 = icmp ult i32 %x5, 100
call void(i1, ...) @llvm.experimental.guard(i1 %c1) [ "deopt"(i64 1) ]
call void(i1, ...) @llvm.experimental.guard(i1 %c5) [ "deopt"(i64 5) ]
br i1 %c2, label %ok, label %out
ok:
call void(i1, ...) @llvm.experimental.guard(i1 %c4) [ "deopt"(i64 4) ]
call void(i1, ...) @llvm.experimental.guard(i1 %c3) [ "deopt"(i64 3) ]
br label %out
out:
ret void
}
; This is similar to @combine_range_checks but shows that simple freeze
; over c3 and c4 will not help due to with X = SMAX_INT, guard with c1 will
; go to deoptimization. But after guard widening freeze of c3 and c4 may return
; true due to c3 and c4 are poisons and we pass guard executing side effect store
; which never been executed in original program.
define void @combine_range_checks_with_side_effect(i32 %x, i32* %p) {
; CHECK-LABEL: @combine_range_checks_with_side_effect(
; CHECK-NEXT: entry:
; CHECK-NEXT: [[X2:%.*]] = add i32 [[X:%.*]], 0
; CHECK-NEXT: [[C2:%.*]] = icmp ult i32 [[X2]], 200
; CHECK-NEXT: [[X3:%.*]] = add nuw nsw i32 [[X]], 3
; CHECK-NEXT: [[C3:%.*]] = icmp ult i32 [[X3]], 100
; CHECK-NEXT: [[X4:%.*]] = add nuw nsw i32 [[X]], 20
; CHECK-NEXT: [[C4:%.*]] = icmp ult i32 [[X4]], 100
; CHECK-NEXT: [[WIDE_CHK2:%.*]] = and i1 [[C4]], [[C3]]
; CHECK-NEXT: call void (i1, ...) @llvm.experimental.guard(i1 [[WIDE_CHK2]]) [ "deopt"(i64 1) ]
; CHECK-NEXT: store i32 0, i32* [[P:%.*]], align 4
; CHECK-NEXT: br i1 [[C2]], label [[OK:%.*]], label [[OUT:%.*]]
; CHECK: ok:
; CHECK-NEXT: br label [[OUT]]
; CHECK: out:
; CHECK-NEXT: ret void
;
entry:
%x1 = add i32 %x, 10
%c1 = icmp ult i32 %x1, 100
%x2 = add i32 %x, 0
%c2 = icmp ult i32 %x2, 200
%x3 = add nuw nsw i32 %x, 3
%c3 = icmp ult i32 %x3, 100
%x4 = add nuw nsw i32 %x, 20
%c4 = icmp ult i32 %x4, 100
%x5 = add i32 %x, 15
%c5 = icmp ult i32 %x5, 100
call void(i1, ...) @llvm.experimental.guard(i1 %c1) [ "deopt"(i64 1) ]
call void(i1, ...) @llvm.experimental.guard(i1 %c5) [ "deopt"(i64 5) ]
store i32 0, i32* %p
br i1 %c2, label %ok, label %out
ok:
call void(i1, ...) @llvm.experimental.guard(i1 %c4) [ "deopt"(i64 4) ]
call void(i1, ...) @llvm.experimental.guard(i1 %c3) [ "deopt"(i64 3) ]
br label %out
out:
ret void
}
; The test shows the bug in guard widening. Critical pieces.
; There is a %cond_1 check which provides the correctness of nuw nsw in %b.shift.
; %b.shift and %cond_2 are poisons and after guard widening it leads to UB
; for both arithmetic and logcal and.
define void @simple_case(i32 %a, i32 %b, i1 %cnd) {
; CHECK-LABEL: @simple_case(
; CHECK-NEXT: entry:
; CHECK-NEXT: [[COND_0:%.*]] = icmp ult i32 [[A:%.*]], 10
; CHECK-NEXT: [[B_SHIFT:%.*]] = add nuw nsw i32 [[B:%.*]], 5
; CHECK-NEXT: [[COND_2:%.*]] = icmp ult i32 [[B_SHIFT]], 10
; CHECK-NEXT: [[WIDE_CHK:%.*]] = and i1 [[COND_0]], [[COND_2]]
; CHECK-NEXT: call void (i1, ...) @llvm.experimental.guard(i1 [[WIDE_CHK]]) [ "deopt"() ]
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[COND_1:%.*]] = icmp ult i32 [[B]], 10
; CHECK-NEXT: br i1 [[COND_1]], label [[OK:%.*]], label [[LEAVE_LOOPEXIT:%.*]]
; CHECK: ok:
; CHECK-NEXT: br i1 [[CND:%.*]], label [[LOOP]], label [[LEAVE_LOOPEXIT]]
; CHECK: leave.loopexit:
; CHECK-NEXT: br label [[LEAVE:%.*]]
; CHECK: leave:
; CHECK-NEXT: ret void
;
entry:
%cond_0 = icmp ult i32 %a, 10
%b.shift = add nuw nsw i32 %b, 5
%cond_2 = icmp ult i32 %b.shift, 10
call void (i1, ...) @llvm.experimental.guard(i1 %cond_0) [ "deopt"() ]
br label %loop
loop:
%cond_1 = icmp ult i32 %b, 10
br i1 %cond_1, label %ok, label %leave.loopexit
ok:
call void (i1, ...) @llvm.experimental.guard(i1 %cond_2) [ "deopt"() ]
br i1 %cnd, label %loop, label %leave.loopexit
leave.loopexit:
br label %leave
leave:
ret void
}
|