maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/PowerPC/optcmp.ll

153 lines
3.6 KiB
LLVM
Raw Normal View History

Disable PPC comparison optimization by default This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do I'm disabling this for now. llvm-svn: 179807
2013-04-19 06:54:25 +08:00
; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -mcpu=a2 -disable-ppc-cmp-opt=0 | FileCheck %s
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
define signext i32 @foo(i32 signext %a, i32 signext %b, i32* nocapture %c) #0 {
entry:
%sub = sub nsw i32 %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i32 %sub, i32* %c, align 4
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = icmp sgt i32 %a, %b
%cond = select i1 %cmp, i32 %a, i32 %b
ret i32 %cond
; CHECK: @foo
; CHECK-NOT: subf.
}
define signext i32 @foo2(i32 signext %a, i32 signext %b, i32* nocapture %c) #0 {
entry:
%shl = shl i32 %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i32 %shl, i32* %c, align 4
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = icmp sgt i32 %shl, 0
%conv = zext i1 %cmp to i32
ret i32 %conv
; CHECK: @foo2
; CHECK-NOT: slw.
}
define i64 @fool(i64 %a, i64 %b, i64* nocapture %c) #0 {
entry:
%sub = sub nsw i64 %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i64 %sub, i64* %c, align 8
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = icmp sgt i64 %a, %b
%cond = select i1 %cmp, i64 %a, i64 %b
ret i64 %cond
; CHECK: @fool
; CHECK: subf. [[REG:[0-9]+]], 4, 3
; CHECK: isel 3, 3, 4, 1
; CHECK: std [[REG]], 0(5)
}
define i64 @foolb(i64 %a, i64 %b, i64* nocapture %c) #0 {
entry:
%sub = sub nsw i64 %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i64 %sub, i64* %c, align 8
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = icmp sle i64 %a, %b
%cond = select i1 %cmp, i64 %a, i64 %b
ret i64 %cond
; CHECK: @foolb
; CHECK: subf. [[REG:[0-9]+]], 4, 3
; CHECK: isel 3, 4, 3, 1
; CHECK: std [[REG]], 0(5)
}
Fix PPC optimizeCompareInstr swapped-sub argument handling When matching a compare with a subtract where the arguments of the compare are swapped w.r.t. the arguments of the subtract, we need to negate the predicates (or CR bit indices) of the users. This, however, is not the same as inverting the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM backend seems to do this correctly, but when I adapted the code for the PPC backend, I introduced an error in this logic. Comparison optimization is now enabled again by default. llvm-svn: 179899
2013-04-20 06:08:38 +08:00
define i64 @foolc(i64 %a, i64 %b, i64* nocapture %c) #0 {
entry:
%sub = sub nsw i64 %b, %a
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i64 %sub, i64* %c, align 8
Fix PPC optimizeCompareInstr swapped-sub argument handling When matching a compare with a subtract where the arguments of the compare are swapped w.r.t. the arguments of the subtract, we need to negate the predicates (or CR bit indices) of the users. This, however, is not the same as inverting the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM backend seems to do this correctly, but when I adapted the code for the PPC backend, I introduced an error in this logic. Comparison optimization is now enabled again by default. llvm-svn: 179899
2013-04-20 06:08:38 +08:00
%cmp = icmp sgt i64 %a, %b
%cond = select i1 %cmp, i64 %a, i64 %b
ret i64 %cond
; CHECK: @foolc
; CHECK: subf. [[REG:[0-9]+]], 3, 4
; CHECK: isel 3, 3, 4, 0
; CHECK: std [[REG]], 0(5)
}
define i64 @foold(i64 %a, i64 %b, i64* nocapture %c) #0 {
entry:
%sub = sub nsw i64 %b, %a
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i64 %sub, i64* %c, align 8
Fix PPC optimizeCompareInstr swapped-sub argument handling When matching a compare with a subtract where the arguments of the compare are swapped w.r.t. the arguments of the subtract, we need to negate the predicates (or CR bit indices) of the users. This, however, is not the same as inverting the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM backend seems to do this correctly, but when I adapted the code for the PPC backend, I introduced an error in this logic. Comparison optimization is now enabled again by default. llvm-svn: 179899
2013-04-20 06:08:38 +08:00
%cmp = icmp eq i64 %a, %b
%cond = select i1 %cmp, i64 %a, i64 %b
ret i64 %cond
; CHECK: @foold
; CHECK: subf. [[REG:[0-9]+]], 3, 4
; CHECK: isel 3, 3, 4, 2
; CHECK: std [[REG]], 0(5)
}
define i64 @foold2(i64 %a, i64 %b, i64* nocapture %c) #0 {
entry:
%sub = sub nsw i64 %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i64 %sub, i64* %c, align 8
Fix PPC optimizeCompareInstr swapped-sub argument handling When matching a compare with a subtract where the arguments of the compare are swapped w.r.t. the arguments of the subtract, we need to negate the predicates (or CR bit indices) of the users. This, however, is not the same as inverting the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM backend seems to do this correctly, but when I adapted the code for the PPC backend, I introduced an error in this logic. Comparison optimization is now enabled again by default. llvm-svn: 179899
2013-04-20 06:08:38 +08:00
%cmp = icmp eq i64 %a, %b
%cond = select i1 %cmp, i64 %a, i64 %b
ret i64 %cond
; CHECK: @foold2
; CHECK: subf. [[REG:[0-9]+]], 4, 3
; CHECK: isel 3, 3, 4, 2
; CHECK: std [[REG]], 0(5)
}
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
define i64 @foo2l(i64 %a, i64 %b, i64* nocapture %c) #0 {
entry:
%shl = shl i64 %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store i64 %shl, i64* %c, align 8
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = icmp sgt i64 %shl, 0
%conv1 = zext i1 %cmp to i64
ret i64 %conv1
; CHECK: @foo2l
; CHECK: sld. 4, 3, 4
; CHECK: std 4, 0(5)
}
define double @food(double %a, double %b, double* nocapture %c) #0 {
entry:
%sub = fsub double %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store double %sub, double* %c, align 8
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = fcmp ogt double %a, %b
%cond = select i1 %cmp, double %a, double %b
ret double %cond
; CHECK: @food
PPCInstrInfo::optimizeCompareInstr should not optimize FP compares The floating-point record forms on PPC don't set the condition register bits based on a comparison with zero (like the integer record forms do), but rather based on the exception status bits. llvm-svn: 181423
2013-05-08 20:16:14 +08:00
; CHECK-NOT: fsub. 0, 1, 2
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
; CHECK: stfd 0, 0(5)
}
define float @foof(float %a, float %b, float* nocapture %c) #0 {
entry:
%sub = fsub float %a, %b
TBAA: remove !tbaa from testing cases when they are not needed. This will make it easier to turn on struct-path aware TBAA since the metadata format will change. llvm-svn: 188944
2013-08-22 06:20:53 +08:00
store float %sub, float* %c, align 4
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
%cmp = fcmp ogt float %a, %b
%cond = select i1 %cmp, float %a, float %b
ret float %cond
; CHECK: @foof
PPCInstrInfo::optimizeCompareInstr should not optimize FP compares The floating-point record forms on PPC don't set the condition register bits based on a comparison with zero (like the integer record forms do), but rather based on the exception status bits. llvm-svn: 181423
2013-05-08 20:16:14 +08:00
; CHECK-NOT: fsubs. 0, 1, 2
Implement optimizeCompareInstr for PPC Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
2013-04-19 06:15:08 +08:00
; CHECK: stfs 0, 0(5)
}
PPC popcnt[dw] do not have record forms The instruction definitions incorrectly specified that popcntd and popcntw have record forms; they do not. This mistake was causing invalid code generation. llvm-svn: 195272
2013-11-21 04:54:55 +08:00
declare i64 @llvm.ctpop.i64(i64);
define signext i64 @fooct(i64 signext %a, i64 signext %b, i64* nocapture %c) #0 {
entry:
%sub = sub nsw i64 %a, %b
%subc = call i64 @llvm.ctpop.i64(i64 %sub)
store i64 %subc, i64* %c, align 4
%cmp = icmp sgt i64 %subc, 0
%cond = select i1 %cmp, i64 %a, i64 %b
ret i64 %cond
; CHECK: @fooct
; CHECK-NOT: popcntd.
}