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/ARM/select_const.ll

245 lines
6.3 KiB
LLVM
Raw Normal View History

[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=arm-eabi-unknown-unknown | FileCheck %s
; Select of constants: control flow / conditional moves can always be replaced by logic+math (but may not be worth it?).
; Test the zeroext/signext variants of each pattern to see if that makes a difference.
; select Cond, 0, 1 --> zext (!Cond)
define i32 @select_0_or_1(i1 %cond) {
; CHECK-LABEL: select_0_or_1:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #1
; CHECK-NEXT: bic r0, r1, r0
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 0, i32 1
ret i32 %sel
}
define i32 @select_0_or_1_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_0_or_1_zeroext:
; CHECK: @ BB#0:
; CHECK-NEXT: eor r0, r0, #1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 0, i32 1
ret i32 %sel
}
define i32 @select_0_or_1_signext(i1 signext %cond) {
; CHECK-LABEL: select_0_or_1_signext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #1
; CHECK-NEXT: bic r0, r1, r0
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 0, i32 1
ret i32 %sel
}
; select Cond, 1, 0 --> zext (Cond)
define i32 @select_1_or_0(i1 %cond) {
; CHECK-LABEL: select_1_or_0:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: and r0, r0, #1
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 1, i32 0
ret i32 %sel
}
define i32 @select_1_or_0_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_1_or_0_zeroext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 1, i32 0
ret i32 %sel
}
define i32 @select_1_or_0_signext(i1 signext %cond) {
; CHECK-LABEL: select_1_or_0_signext:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: and r0, r0, #1
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 1, i32 0
ret i32 %sel
}
; select Cond, 0, -1 --> sext (!Cond)
define i32 @select_0_or_neg1(i1 %cond) {
; CHECK-LABEL: select_0_or_neg1:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: mov r1, #1
; CHECK-NEXT: bic r0, r1, r0
; CHECK-NEXT: rsb r0, r0, #0
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 0, i32 -1
ret i32 %sel
}
define i32 @select_0_or_neg1_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_0_or_neg1_zeroext:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: eor r0, r0, #1
; CHECK-NEXT: rsb r0, r0, #0
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 0, i32 -1
ret i32 %sel
}
define i32 @select_0_or_neg1_signext(i1 signext %cond) {
; CHECK-LABEL: select_0_or_neg1_signext:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: mvn r0, r0
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 0, i32 -1
ret i32 %sel
}
; select Cond, -1, 0 --> sext (Cond)
define i32 @select_neg1_or_0(i1 %cond) {
; CHECK-LABEL: select_neg1_or_0:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: and r0, r0, #1
; CHECK-NEXT: rsb r0, r0, #0
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 -1, i32 0
ret i32 %sel
}
define i32 @select_neg1_or_0_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_neg1_or_0_zeroext:
; CHECK: @ BB#0:
[DAGCombiner] add missing folds for scalar select of {-1,0,1} The motivation for filling out these select-of-constants cases goes back to D24480, where we discussed removing an IR fold from add(zext) --> select. And that goes back to: https://reviews.llvm.org/rL75531 https://reviews.llvm.org/rL159230 The idea is that we should always canonicalize patterns like this to a select-of-constants in IR because that's the smallest IR and the best for value tracking. Note that we currently do the opposite in some cases (like the cases in *this* patch). Ie, the proposed folds in this patch already exist in InstCombine today: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1151 As this patch shows, most targets generate better machine code for simple ext/add/not ops rather than a select of constants. So the follow-up steps to make this less of a patchwork of special-case folds and missing IR canonicalization: 1. Have DAGCombiner convert any select of constants into ext/add/not ops. 2 Have InstCombine canonicalize in the other direction (create more selects). Differential Revision: https://reviews.llvm.org/D30180 llvm-svn: 296137
2017-02-25 01:17:33 +08:00
; CHECK-NEXT: rsb r0, r0, #0
[ARM] add tests for select-of-constants; NFC llvm-svn: 295459
2017-02-18 00:34:13 +08:00
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 -1, i32 0
ret i32 %sel
}
define i32 @select_neg1_or_0_signext(i1 signext %cond) {
; CHECK-LABEL: select_neg1_or_0_signext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 -1, i32 0
ret i32 %sel
}
; select Cond, C+1, C --> add (zext Cond), C
define i32 @select_Cplus1_C(i1 %cond) {
; CHECK-LABEL: select_Cplus1_C:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #41
; CHECK-NEXT: tst r0, #1
; CHECK-NEXT: movne r1, #42
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 42, i32 41
ret i32 %sel
}
define i32 @select_Cplus1_C_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_Cplus1_C_zeroext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #41
; CHECK-NEXT: cmp r0, #0
; CHECK-NEXT: movne r1, #42
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 42, i32 41
ret i32 %sel
}
define i32 @select_Cplus1_C_signext(i1 signext %cond) {
; CHECK-LABEL: select_Cplus1_C_signext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #41
; CHECK-NEXT: tst r0, #1
; CHECK-NEXT: movne r1, #42
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 42, i32 41
ret i32 %sel
}
; select Cond, C, C+1 --> add (sext Cond), C
define i32 @select_C_Cplus1(i1 %cond) {
; CHECK-LABEL: select_C_Cplus1:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #42
; CHECK-NEXT: tst r0, #1
; CHECK-NEXT: movne r1, #41
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 41, i32 42
ret i32 %sel
}
define i32 @select_C_Cplus1_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_C_Cplus1_zeroext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #42
; CHECK-NEXT: cmp r0, #0
; CHECK-NEXT: movne r1, #41
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 41, i32 42
ret i32 %sel
}
define i32 @select_C_Cplus1_signext(i1 signext %cond) {
; CHECK-LABEL: select_C_Cplus1_signext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #42
; CHECK-NEXT: tst r0, #1
; CHECK-NEXT: movne r1, #41
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 41, i32 42
ret i32 %sel
}
; In general, select of 2 constants could be:
; select Cond, C1, C2 --> add (mul (zext Cond), C1-C2), C2 --> add (and (sext Cond), C1-C2), C2
define i32 @select_C1_C2(i1 %cond) {
; CHECK-LABEL: select_C1_C2:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #165
; CHECK-NEXT: tst r0, #1
; CHECK-NEXT: orr r1, r1, #256
; CHECK-NEXT: moveq r1, #42
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 421, i32 42
ret i32 %sel
}
define i32 @select_C1_C2_zeroext(i1 zeroext %cond) {
; CHECK-LABEL: select_C1_C2_zeroext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #165
; CHECK-NEXT: cmp r0, #0
; CHECK-NEXT: orr r1, r1, #256
; CHECK-NEXT: moveq r1, #42
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 421, i32 42
ret i32 %sel
}
define i32 @select_C1_C2_signext(i1 signext %cond) {
; CHECK-LABEL: select_C1_C2_signext:
; CHECK: @ BB#0:
; CHECK-NEXT: mov r1, #165
; CHECK-NEXT: tst r0, #1
; CHECK-NEXT: orr r1, r1, #256
; CHECK-NEXT: moveq r1, #42
; CHECK-NEXT: mov r0, r1
; CHECK-NEXT: mov pc, lr
%sel = select i1 %cond, i32 421, i32 42
ret i32 %sel
}