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/select-i1-vs-i1.ll

1797 lines
55 KiB
LLVM
Raw Normal View History

Adding -verify-machineinstrs option to PowerPC tests Currently we have a number of tests that fail with -verify-machineinstrs. To detect this cases earlier we add the option to the testcases with the exception of tests that will currently fail with this option. PR 27456 keeps track of this failures. No code review, as discussed with Hal Finkel. llvm-svn: 277624
2016-08-04 02:17:35 +08:00
; RUN: llc -verify-machineinstrs < %s | FileCheck %s
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; RUN: llc -verify-machineinstrs -ppc-gen-isel=false < %s | FileCheck --check-prefix=CHECK-NO-ISEL %s
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
; FIXME: We should check the operands to the cr* logical operation itself, but
; unfortunately, FileCheck does not yet understand how to do arithmetic, so we
; can't do so without introducing a register-allocation dependency.
define signext i32 @testi32slt(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32slt
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32slt
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32ult(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32ult
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32sle(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32sle
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32sle
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32ule(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32ule
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32ule
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32eq(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32eq
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32eq
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32sge(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32sge
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32sge
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32uge(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32uge
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32uge
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32sgt(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32sgt
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32sgt
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32ugt(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32ugt
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32ugt
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define signext i32 @testi32ne(i32 signext %c1, i32 signext %c2, i32 signext %c3, i32 signext %c4, i32 signext %a1, i32 signext %a2) #0 {
entry:
%cmp1 = icmp eq i32 %c3, %c4
%cmp3tmp = icmp eq i32 %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i32 %a1, i32 %a2
ret i32 %cond
; CHECK-LABEL: @testi32ne
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi32ne
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpw {{[0-9]+}}, 5, 6
; CHECK-DAG: cmpw {{[0-9]+}}, 3, 4
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64slt(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64slt
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64slt
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64ult(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64ult
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64ult
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64sle(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64sle
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64sle
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64ule(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64ule
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64ule
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64eq(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64eq
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64eq
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64sge(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64sge
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64sge
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64uge(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64uge
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64uge
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64sgt(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64sgt
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64sgt
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64ugt(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64ugt
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64ugt
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define i64 @testi64ne(i64 %c1, i64 %c2, i64 %c3, i64 %c4, i64 %a1, i64 %a2) #0 {
entry:
%cmp1 = icmp eq i64 %c3, %c4
%cmp3tmp = icmp eq i64 %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, i64 %a1, i64 %a2
ret i64 %cond
; CHECK-LABEL: @testi64ne
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL-LABEL: @testi64ne
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK-DAG: cmpd {{([0-9]+, )?}}5, 6
; CHECK-DAG: cmpd {{([0-9]+, )?}}3, 4
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: isel 3, 7, 8, [[REG1]]
[PowerPC] Expand ISEL instruction into if-then-else sequence. Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154
2017-01-17 04:12:26 +08:00
; CHECK-NO-ISEL: bc 12, 20, [[TRUE:.LBB[0-9]+]]
; CHECK-NO-ISEL: ori 3, 8, 0
; CHECK-NO-ISEL-NEXT: blr
; CHECK-NO-ISEL: [[TRUE]]
; CHECK-NO-ISEL-NEXT: addi 3, 7, 0
; CHECK-NO-ISEL-NEXT: blr
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define float @testfloatslt(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatslt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatult(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatsle(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatsle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatule(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloateq(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloateq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatsge(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatsge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatuge(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatuge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatsgt(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatsgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatugt(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define float @testfloatne(float %c1, float %c2, float %c3, float %c4, float %a1, float %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, float %a1, float %a2
ret float %cond
; CHECK-LABEL: @testfloatne
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoubleslt(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoubleslt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoubleult(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoubleult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoublesle(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoublesle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoubleule(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoubleule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoubleeq(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoubleeq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoublesge(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoublesge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoubleuge(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoubleuge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoublesgt(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoublesgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoubleugt(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoubleugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define double @testdoublene(double %c1, double %c2, double %c3, double %c4, double %a1, double %a2) #0 {
entry:
%cmp1 = fcmp oeq double %c3, %c4
%cmp3tmp = fcmp oeq double %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, double %a1, double %a2
ret double %cond
; CHECK-LABEL: @testdoublene
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: fmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: fmr 1, 5
; CHECK: blr
}
define <4 x float> @testv4floatslt(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatslt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatult(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatsle(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatsle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatule(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floateq(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floateq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB1:[0-9_]+]]
; CHECK: vor 3, 2, 2
; CHECK: .LBB[[BB1]]
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatsge(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatsge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatuge(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatuge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatsgt(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatsgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatugt(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <4 x float> @testv4floatne(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testv4floatne
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define ppc_fp128 @testppc_fp128eq(ppc_fp128 %c1, ppc_fp128 %c2, ppc_fp128 %c3, ppc_fp128 %c4, ppc_fp128 %a1, ppc_fp128 %a2) #0 {
entry:
%cmp1 = fcmp oeq ppc_fp128 %c3, %c4
%cmp3tmp = fcmp oeq ppc_fp128 %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, ppc_fp128 %a1, ppc_fp128 %a2
ret ppc_fp128 %cond
; FIXME: Because of the way that the late SELECT_* pseudo-instruction expansion
; works, we end up with two blocks with the same predicate. These could be
; combined.
; CHECK-LABEL: @testppc_fp128eq
; CHECK-DAG: fcmpu {{[0-9]+}}, 6, 8
; CHECK-DAG: fcmpu {{[0-9]+}}, 5, 7
; CHECK-DAG: fcmpu {{[0-9]+}}, 2, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 3
; CHECK: crand [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: crand [[REG2:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
Remove MVT:i1 xor instruction before SELECT. (Performance improvement). Differential Revision: https://reviews.llvm.org/D23764 llvm-svn: 281308
2016-09-13 17:12:45 +08:00
; CHECK: crxor [[REG3:[0-9]+]], [[REG2]], [[REG1]]
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: bc 12, [[REG3]], .LBB[[BB1:[0-9_]+]]
Remove MVT:i1 xor instruction before SELECT. (Performance improvement). Differential Revision: https://reviews.llvm.org/D23764 llvm-svn: 281308
2016-09-13 17:12:45 +08:00
; CHECK: fmr 11, 9
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: .LBB[[BB1]]:
; CHECK: bc 12, [[REG3]], .LBB[[BB2:[0-9_]+]]
Remove MVT:i1 xor instruction before SELECT. (Performance improvement). Differential Revision: https://reviews.llvm.org/D23764 llvm-svn: 281308
2016-09-13 17:12:45 +08:00
; CHECK: fmr 12, 10
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: .LBB[[BB2]]:
Remove MVT:i1 xor instruction before SELECT. (Performance improvement). Differential Revision: https://reviews.llvm.org/D23764 llvm-svn: 281308
2016-09-13 17:12:45 +08:00
; CHECK-DAG: fmr 1, 11
; CHECK-DAG: fmr 2, 12
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <2 x double> @testv2doubleslt(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doubleslt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doubleult(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doubleult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doublesle(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doublesle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doubleule(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doubleule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doubleeq(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doubleeq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
Remove MVT:i1 xor instruction before SELECT. (Performance improvement). Differential Revision: https://reviews.llvm.org/D23764 llvm-svn: 281308
2016-09-13 17:12:45 +08:00
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB55:[0-9_]+]]
; CHECK: vor 3, 2, 2
; CHECK: .LBB[[BB55]]
[Power9] Part-word VSX integer scalar loads/stores and sign extend instructions This patch corresponds to review: https://reviews.llvm.org/D23155 This patch removes the VSHRC register class (based on D20310) and adds exploitation of the Power9 sub-word integer loads into VSX registers as well as vector sign extensions. The new instructions are useful for a few purposes: Int to Fp conversions of 1 or 2-byte values loaded from memory Building vectors of 1 or 2-byte integers with values loaded from memory Storing individual 1 or 2-byte elements from integer vectors This patch implements all of those uses. llvm-svn: 283190
2016-10-04 14:59:23 +08:00
; CHECK: vor 2, 3, 3
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
2015-08-31 06:12:50 +08:00
; CHECK: blr
}
define <2 x double> @testv2doublesge(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doublesge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doubleuge(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doubleuge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doublesgt(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doublesgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doubleugt(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doubleugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <2 x double> @testv2doublene(float %c1, float %c2, float %c3, float %c4, <2 x double> %a1, <2 x double> %a2) #0 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <2 x double> %a1, <2 x double> %a2
ret <2 x double> %cond
; CHECK-LABEL: @testv2doublene
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bclr 12, [[REG1]], 0
; CHECK: vor 2, 3, 3
; CHECK: blr
}
define <4 x double> @testqv4doubleslt(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doubleslt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doubleult(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doubleult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doublesle(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doublesle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doubleule(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doubleule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doubleeq(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doubleeq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doublesge(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doublesge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doubleuge(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doubleuge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doublesgt(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doublesgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doubleugt(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doubleugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x double> @testqv4doublene(float %c1, float %c2, float %c3, float %c4, <4 x double> %a1, <4 x double> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x double> %a1, <4 x double> %a2
ret <4 x double> %cond
; CHECK-LABEL: @testqv4doublene
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatslt(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatslt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatult(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatsle(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatsle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatule(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floateq(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floateq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatsge(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatsge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatuge(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatuge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatsgt(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatsgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatugt(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x float> @testqv4floatne(float %c1, float %c2, float %c3, float %c4, <4 x float> %a1, <4 x float> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x float> %a1, <4 x float> %a2
ret <4 x float> %cond
; CHECK-LABEL: @testqv4floatne
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1slt(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp slt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1slt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1ult(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ult i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1ult
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1sle(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sle i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1sle
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1ule(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ule i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1ule
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1eq(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp eq i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1eq
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: creqv [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1sge(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1sge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1uge(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp uge i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1uge
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crorc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1sgt(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp sgt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1sgt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1ugt(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ugt i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1ugt
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crandc [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
define <4 x i1> @testqv4i1ne(float %c1, float %c2, float %c3, float %c4, <4 x i1> %a1, <4 x i1> %a2) #1 {
entry:
%cmp1 = fcmp oeq float %c3, %c4
%cmp3tmp = fcmp oeq float %c1, %c2
%cmp3 = icmp ne i1 %cmp3tmp, %cmp1
%cond = select i1 %cmp3, <4 x i1> %a1, <4 x i1> %a2
ret <4 x i1> %cond
; CHECK-LABEL: @testqv4i1ne
; CHECK-DAG: fcmpu {{[0-9]+}}, 3, 4
; CHECK-DAG: fcmpu {{[0-9]+}}, 1, 2
; CHECK: crxor [[REG1:[0-9]+]], {{[0-9]+}}, {{[0-9]+}}
; CHECK: bc 12, [[REG1]], .LBB[[BB:[0-9_]+]]
; CHECK: qvfmr 5, 6
; CHECK: .LBB[[BB]]:
; CHECK: qvfmr 1, 5
; CHECK: blr
}
attributes #0 = { nounwind readnone "target-cpu"="pwr7" }
attributes #1 = { nounwind readnone "target-cpu"="a2q" }