RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-29 23:12:55 +01:00
Code Issues Projects Releases Wiki Activity
b2557b7cf1
llvm-mirror/test/Transforms/InstSimplify/compare.ll

287 lines
4.8 KiB
LLVM
Raw Normal View History

At -O123 the early-cse pass is run before instcombine has run. According to my auto-simplier the transform most missed by early-cse is (zext X) != 0 -> X != 0. This patch adds this transform and some related logic to InstructionSimplify and removes some of the logic from instcombine (unfortunately not all because there are several situations in which instcombine can improve things by making new instructions, whereas instsimplify is not allowed to do this). At -O2 this often results in more than 15% more simplifications by early-cse, and results in hundreds of lines of bitcode being eliminated from the testsuite. I did see some small negative effects in the testsuite, for example a few additional instructions in three programs. One program, 483.xalancbmk, got an additional 35 instructions, which seems to be due to a function getting an additional instruction and then being inlined all over the place. llvm-svn: 123911
2011-01-20 14:21:55 +01:00
; RUN: opt < %s -instsimplify -S | FileCheck %s
target datalayout = "p:32:32"
define i1 @ptrtoint() {
; CHECK: @ptrtoint
%a = alloca i8
%tmp = ptrtoint i8* %a to i32
%r = icmp eq i32 %tmp, 0
ret i1 %r
; CHECK: ret i1 false
}
define i1 @zext(i32 %x) {
; CHECK: @zext
%e1 = zext i32 %x to i64
%e2 = zext i32 %x to i64
%r = icmp eq i64 %e1, %e2
ret i1 %r
; CHECK: ret i1 true
}
define i1 @zext2(i1 %x) {
; CHECK: @zext2
%e = zext i1 %x to i32
%c = icmp ne i32 %e, 0
ret i1 %c
; CHECK: ret i1 %x
}
According to my auto-simplifier the most common missed simplifications in optimized code are: (non-negative number)+(power-of-two) != 0 -> true and (x | 1) != 0 -> true Instcombine knows about the second one of course, but only does it if X|1 has only one use. These fire thousands of times in the testsuite. llvm-svn: 124183
2011-01-25 10:38:29 +01:00
define i1 @zext3() {
; CHECK: @zext3
%e = zext i1 1 to i32
%c = icmp ne i32 %e, 0
ret i1 %c
; CHECK: ret i1 true
}
At -O123 the early-cse pass is run before instcombine has run. According to my auto-simplier the transform most missed by early-cse is (zext X) != 0 -> X != 0. This patch adds this transform and some related logic to InstructionSimplify and removes some of the logic from instcombine (unfortunately not all because there are several situations in which instcombine can improve things by making new instructions, whereas instsimplify is not allowed to do this). At -O2 this often results in more than 15% more simplifications by early-cse, and results in hundreds of lines of bitcode being eliminated from the testsuite. I did see some small negative effects in the testsuite, for example a few additional instructions in three programs. One program, 483.xalancbmk, got an additional 35 instructions, which seems to be due to a function getting an additional instruction and then being inlined all over the place. llvm-svn: 123911
2011-01-20 14:21:55 +01:00
define i1 @sext(i32 %x) {
; CHECK: @sext
%e1 = sext i32 %x to i64
%e2 = sext i32 %x to i64
%r = icmp eq i64 %e1, %e2
ret i1 %r
; CHECK: ret i1 true
}
define i1 @sext2(i1 %x) {
; CHECK: @sext2
%e = sext i1 %x to i32
%c = icmp ne i32 %e, 0
ret i1 %c
; CHECK: ret i1 %x
}
According to my auto-simplifier the most common missed simplifications in optimized code are: (non-negative number)+(power-of-two) != 0 -> true and (x | 1) != 0 -> true Instcombine knows about the second one of course, but only does it if X|1 has only one use. These fire thousands of times in the testsuite. llvm-svn: 124183
2011-01-25 10:38:29 +01:00
define i1 @sext3() {
; CHECK: @sext3
%e = sext i1 1 to i32
%c = icmp ne i32 %e, 0
ret i1 %c
; CHECK: ret i1 true
}
define i1 @add(i32 %x, i32 %y) {
In which I discover that zero+zero is zero, d'oh! llvm-svn: 124188
2011-01-25 16:14:15 +01:00
; CHECK: @add
According to my auto-simplifier the most common missed simplifications in optimized code are: (non-negative number)+(power-of-two) != 0 -> true and (x | 1) != 0 -> true Instcombine knows about the second one of course, but only does it if X|1 has only one use. These fire thousands of times in the testsuite. llvm-svn: 124183
2011-01-25 10:38:29 +01:00
%l = lshr i32 %x, 1
In which I discover that zero+zero is zero, d'oh! llvm-svn: 124188
2011-01-25 16:14:15 +01:00
%q = lshr i32 %y, 1
%r = or i32 %q, 1
According to my auto-simplifier the most common missed simplifications in optimized code are: (non-negative number)+(power-of-two) != 0 -> true and (x | 1) != 0 -> true Instcombine knows about the second one of course, but only does it if X|1 has only one use. These fire thousands of times in the testsuite. llvm-svn: 124183
2011-01-25 10:38:29 +01:00
%s = add i32 %l, %r
%c = icmp eq i32 %s, 0
ret i1 %c
In which I discover that zero+zero is zero, d'oh! llvm-svn: 124188
2011-01-25 16:14:15 +01:00
; CHECK: ret i1 false
According to my auto-simplifier the most common missed simplifications in optimized code are: (non-negative number)+(power-of-two) != 0 -> true and (x | 1) != 0 -> true Instcombine knows about the second one of course, but only does it if X|1 has only one use. These fire thousands of times in the testsuite. llvm-svn: 124183
2011-01-25 10:38:29 +01:00
}
define i1 @add2(i8 %x, i8 %y) {
; CHECK: @add2
%l = or i8 %x, 128
%r = or i8 %y, 129
%s = add i8 %l, %r
%c = icmp eq i8 %s, 0
ret i1 %c
; CHECK: ret i1 false
}
In which I discover that zero+zero is zero, d'oh! llvm-svn: 124188
2011-01-25 16:14:15 +01:00
define i1 @add3(i8 %x, i8 %y) {
; CHECK: @add3
%l = zext i8 %x to i32
%r = zext i8 %y to i32
%s = add i32 %l, %r
%c = icmp eq i32 %s, 0
ret i1 %c
; CHECK: ret i1 %c
}
Teach instsimplify that X+Y>=X+Z is the same as Y>=Z if neither side overflows, plus some variations of this. According to my auto-simplifier this occurs a lot but usually in combination with max/min idioms. Because max/min aren't handled yet this unfortunately doesn't have much effect in the testsuite. llvm-svn: 125462
2011-02-13 18:15:40 +01:00
define i1 @add4(i32 %x, i32 %y) {
; CHECK: @add4
%z = add nsw i32 %y, 1
%s1 = add nsw i32 %x, %y
%s2 = add nsw i32 %x, %z
%c = icmp slt i32 %s1, %s2
ret i1 %c
; CHECK: ret i1 true
}
define i1 @add5(i32 %x, i32 %y) {
; CHECK: @add5
%z = add nuw i32 %y, 1
%s1 = add nuw i32 %x, %z
%s2 = add nuw i32 %x, %y
%c = icmp ugt i32 %s1, %s2
ret i1 %c
; CHECK: ret i1 true
}
According to my auto-simplifier the most common missed simplifications in optimized code are: (non-negative number)+(power-of-two) != 0 -> true and (x | 1) != 0 -> true Instcombine knows about the second one of course, but only does it if X|1 has only one use. These fire thousands of times in the testsuite. llvm-svn: 124183
2011-01-25 10:38:29 +01:00
define i1 @addpowtwo(i32 %x, i32 %y) {
; CHECK: @addpowtwo
%l = lshr i32 %x, 1
%r = shl i32 1, %y
%s = add i32 %l, %r
%c = icmp eq i32 %s, 0
ret i1 %c
; CHECK: ret i1 false
}
define i1 @or(i32 %x) {
; CHECK: @or
%o = or i32 %x, 1
%c = icmp eq i32 %o, 0
ret i1 %c
; CHECK: ret i1 false
}
Fix typo: should have been testing that X was odd, not V. llvm-svn: 124533
2011-01-29 14:27:00 +01:00
define i1 @shl(i32 %x) {
; CHECK: @shl
%s = shl i32 1, %x
%c = icmp eq i32 %s, 0
ret i1 %c
; CHECK: ret i1 false
}
Teach instruction simplify to use constant ranges to solve problems of the form "icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2". Some of these cases (div and rem) used to make it through opt -O2, but the others are probably now making code elsewhere redundant (probably instcombine). llvm-svn: 126988
2011-03-04 08:00:57 +01:00
define i1 @lshr1(i32 %x) {
; CHECK: @lshr1
Fix typo: should have been testing that X was odd, not V. llvm-svn: 124533
2011-01-29 14:27:00 +01:00
%s = lshr i32 -1, %x
%c = icmp eq i32 %s, 0
ret i1 %c
; CHECK: ret i1 false
}
Teach instruction simplify to use constant ranges to solve problems of the form "icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2". Some of these cases (div and rem) used to make it through opt -O2, but the others are probably now making code elsewhere redundant (probably instcombine). llvm-svn: 126988
2011-03-04 08:00:57 +01:00
define i1 @lshr2(i32 %x) {
; CHECK: @lshr2
%s = lshr i32 %x, 30
%c = icmp ugt i32 %s, 8
ret i1 %c
; CHECK: ret i1 false
}
define i1 @ashr1(i32 %x) {
; CHECK: @ashr1
Fix typo: should have been testing that X was odd, not V. llvm-svn: 124533
2011-01-29 14:27:00 +01:00
%s = ashr i32 -1, %x
%c = icmp eq i32 %s, 0
ret i1 %c
; CHECK: ret i1 false
}
Improve threading of comparisons over select instructions (spotted by my auto-simplifier). This has a big impact on Ada code, but not much else. Unfortunately the impact is mostly negative! This is due to PR9004 (aka SCCP failing to resolve conditional branch conditions in the destination blocks of the branch), in which simple correlated expressions are not resolved but complicated ones are, so simplifying has a bad effect! llvm-svn: 124788
2011-02-03 10:37:39 +01:00
Teach instruction simplify to use constant ranges to solve problems of the form "icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2". Some of these cases (div and rem) used to make it through opt -O2, but the others are probably now making code elsewhere redundant (probably instcombine). llvm-svn: 126988
2011-03-04 08:00:57 +01:00
define i1 @ashr2(i32 %x) {
; CHECK: @ashr2
%s = ashr i32 %x, 30
%c = icmp slt i32 %s, -5
ret i1 %c
; CHECK: ret i1 false
}
Improve threading of comparisons over select instructions (spotted by my auto-simplifier). This has a big impact on Ada code, but not much else. Unfortunately the impact is mostly negative! This is due to PR9004 (aka SCCP failing to resolve conditional branch conditions in the destination blocks of the branch), in which simple correlated expressions are not resolved but complicated ones are, so simplifying has a bad effect! llvm-svn: 124788
2011-02-03 10:37:39 +01:00
define i1 @select1(i1 %cond) {
; CHECK: @select1
%s = select i1 %cond, i32 1, i32 0
%c = icmp eq i32 %s, 1
ret i1 %c
; CHECK: ret i1 %cond
}
define i1 @select2(i1 %cond) {
; CHECK: @select2
%x = zext i1 %cond to i32
%s = select i1 %cond, i32 %x, i32 0
%c = icmp ne i32 %s, 0
ret i1 %c
; CHECK: ret i1 %cond
}
define i1 @select3(i1 %cond) {
; CHECK: @select3
%x = zext i1 %cond to i32
%s = select i1 %cond, i32 1, i32 %x
%c = icmp ne i32 %s, 0
ret i1 %c
; CHECK: ret i1 %cond
}
define i1 @select4(i1 %cond) {
; CHECK: @select4
%invert = xor i1 %cond, 1
%s = select i1 %invert, i32 0, i32 1
%c = icmp ne i32 %s, 0
ret i1 %c
; CHECK: ret i1 %cond
}
Optimize "icmp pred (urem X, Y), Y" --> true/false depending on pred. There's more work to do here, "icmp ult (urem X, 10), 11" doesn't optimize away yet. Fixes example 3 from PR9343! llvm-svn: 126741
2011-03-01 09:15:50 +01:00
define i1 @urem1(i32 %X, i32 %Y) {
; CHECK: @urem1
%A = urem i32 %X, %Y
%B = icmp ult i32 %A, %Y
ret i1 %B
; CHECK: ret i1 true
}
define i1 @urem2(i32 %X, i32 %Y) {
; CHECK: @urem2
%A = urem i32 %X, %Y
%B = icmp eq i32 %A, %Y
ret i1 %B
; CHECK ret i1 false
}
Teach instruction simplify to use constant ranges to solve problems of the form "icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2". Some of these cases (div and rem) used to make it through opt -O2, but the others are probably now making code elsewhere redundant (probably instcombine). llvm-svn: 126988
2011-03-04 08:00:57 +01:00
define i1 @urem3(i32 %X) {
; CHECK: @urem3
%A = urem i32 %X, 10
%B = icmp ult i32 %A, 15
ret i1 %B
; CHECK: ret i1 true
}
define i1 @urem4(i32 %X) {
; CHECK: @urem4
%A = urem i32 %X, 15
%B = icmp ult i32 %A, 10
ret i1 %B
; CHECK: ret i1 %B
}
Fold "icmp pred (srem X, Y), Y" like we do for urem. Handle signed comparisons in the urem case, though not the other way around. This is enough to get #3 from PR9343! llvm-svn: 126991
2011-03-04 11:06:52 +01:00
define i1 @urem5(i16 %X, i32 %Y) {
; CHECK: @urem5
%A = zext i16 %X to i32
%B = urem i32 %A, %Y
%C = icmp slt i32 %B, %Y
ret i1 %C
; CHECK: ret i1 true
}
Teach instruction simplify to use constant ranges to solve problems of the form "icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2". Some of these cases (div and rem) used to make it through opt -O2, but the others are probably now making code elsewhere redundant (probably instcombine). llvm-svn: 126988
2011-03-04 08:00:57 +01:00
define i1 @srem1(i32 %X) {
; CHECK: @srem1
%A = srem i32 %X, -5
%B = icmp sgt i32 %A, 5
ret i1 %B
; CHECK: ret i1 false
}
define i1 @udiv1(i32 %X) {
; CHECK: @udiv1
%A = udiv i32 %X, 1000000
%B = icmp ult i32 %A, 5000
ret i1 %B
; CHECK: ret i1 true
}
define i1 @sdiv1(i32 %X) {
; CHECK: @sdiv1
%A = sdiv i32 %X, 1000000
%B = icmp slt i32 %A, 3000
ret i1 %B
; CHECK: ret i1 true
}
define i1 @or1(i32 %X) {
; CHECK: @or1
%A = or i32 %X, 62
%B = icmp ult i32 %A, 50
ret i1 %B
; CHECK: ret i1 false
}
define i1 @and1(i32 %X) {
; CHECK: @and1
%A = and i32 %X, 62
%B = icmp ugt i32 %A, 70
ret i1 %B
; CHECK: ret i1 false
}
Reference in New Issue Copy Permalink