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

320 lines
8.9 KiB
LLVM
Raw Normal View History

[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[x86] regenerate checks llvm-svn: 284982
2016-10-24 23:43:40 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown | FileCheck %s
Reapply r165661, Patch by Shuxin Yang <shuxin.llvm@gmail.com>. Original message: The attached is the fix to radar://11663049. The optimization can be outlined by following rules: (select (x != c), e, c) -> select (x != c), e, x), (select (x == c), c, e) -> select (x == c), x, e) where the <c> is an integer constant. The reason for this change is that : on x86, conditional-move-from-constant needs two instructions; however, conditional-move-from-register need only one instruction. While the LowerSELECT() sounds to be the most convenient place for this optimization, it turns out to be a bad place. The reason is that by replacing the constant <c> with a symbolic value, it obscure some instruction-combining opportunities which would otherwise be very easy to spot. For that reason, I have to postpone the change to last instruction-combining phase. The change passes the test of "make check-all -C <build-root/test" and "make -C project/test-suite/SingleSource". Original message since r165661: My previous change has a bug: I negated the condition code of a CMOV, and go ahead creating a new CMOV using the *ORIGINAL* condition code. llvm-svn: 166017
2012-10-16 14:28:34 +08:00
[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
; 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)
[x86] add tests for {-1,0,1} select of constants llvm-svn: 285005
2016-10-25 03:13:29 +08:00
define i32 @select_0_or_1(i1 %cond) {
; CHECK-LABEL: select_0_or_1:
; CHECK: # BB#0:
; CHECK-NEXT: notb %dil
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: andl $1, %eax
; CHECK-NEXT: retq
%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: xorb $1, %dil
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 0, i32 1
ret i32 %sel
}
[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
define i32 @select_0_or_1_signext(i1 signext %cond) {
; CHECK-LABEL: select_0_or_1_signext:
; CHECK: # BB#0:
; CHECK-NEXT: notb %dil
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: andl $1, %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 0, i32 1
ret i32 %sel
}
; select Cond, 1, 0 --> zext (Cond)
[x86] add tests for {-1,0,1} select of constants llvm-svn: 285005
2016-10-25 03:13:29 +08:00
define i32 @select_1_or_0(i1 %cond) {
; CHECK-LABEL: select_1_or_0:
; CHECK: # BB#0:
; CHECK-NEXT: andl $1, %edi
; CHECK-NEXT: movl %edi, %eax
; CHECK-NEXT: retq
%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: movzbl %dil, %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 1, i32 0
ret i32 %sel
}
[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
define i32 @select_1_or_0_signext(i1 signext %cond) {
; CHECK-LABEL: select_1_or_0_signext:
; CHECK: # BB#0:
; CHECK-NEXT: andb $1, %dil
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 1, i32 0
ret i32 %sel
}
; select Cond, 0, -1 --> sext (!Cond)
[x86] add tests for {-1,0,1} select of constants llvm-svn: 285005
2016-10-25 03:13:29 +08:00
define i32 @select_0_or_neg1(i1 %cond) {
; CHECK-LABEL: select_0_or_neg1:
; CHECK: # BB#0:
; CHECK-NEXT: # kill: %EDI<def> %EDI<kill> %RDI<def>
; CHECK-NEXT: andl $1, %edi
; CHECK-NEXT: leal -1(%rdi), %eax
; CHECK-NEXT: retq
%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:
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: decl %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 0, i32 -1
ret i32 %sel
}
[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
define i32 @select_0_or_neg1_signext(i1 signext %cond) {
; CHECK-LABEL: select_0_or_neg1_signext:
; CHECK: # BB#0:
; CHECK-NEXT: andb $1, %dil
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: decl %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 0, i32 -1
ret i32 %sel
}
; select Cond, -1, 0 --> sext (Cond)
[x86] add tests for {-1,0,1} select of constants llvm-svn: 285005
2016-10-25 03:13:29 +08:00
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: andl $1, %edi
; CHECK-NEXT: negl %edi
; CHECK-NEXT: movl %edi, %eax
[x86] add tests for {-1,0,1} select of constants llvm-svn: 285005
2016-10-25 03:13:29 +08:00
; CHECK-NEXT: retq
%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: movzbl %dil, %eax
; CHECK-NEXT: negl %eax
[x86] add tests for {-1,0,1} select of constants llvm-svn: 285005
2016-10-25 03:13:29 +08:00
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 -1, i32 0
ret i32 %sel
}
[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
define i32 @select_neg1_or_0_signext(i1 signext %cond) {
; CHECK-LABEL: select_neg1_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: movsbl %dil, %eax
[x86] add more tests of select of constants; NFC llvm-svn: 295346
2017-02-17 02:15:16 +08:00
; CHECK-NEXT: retq
%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: # kill: %EDI<def> %EDI<kill> %RDI<def>
; CHECK-NEXT: andl $1, %edi
; CHECK-NEXT: leal 41(%rdi), %eax
; CHECK-NEXT: retq
%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: movzbl %dil, %eax
; CHECK-NEXT: addl $41, %eax
; CHECK-NEXT: retq
%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: andb $1, %dil
; CHECK-NEXT: movzbl %dil, %eax
; CHECK-NEXT: addl $41, %eax
; CHECK-NEXT: retq
%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: andb $1, %dil
; CHECK-NEXT: cmpb $1, %dil
; CHECK-NEXT: movl $41, %eax
; CHECK-NEXT: adcl $0, %eax
; CHECK-NEXT: retq
%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: cmpb $1, %dil
; CHECK-NEXT: movl $41, %eax
; CHECK-NEXT: adcl $0, %eax
; CHECK-NEXT: retq
%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: andb $1, %dil
; CHECK-NEXT: cmpb $1, %dil
; CHECK-NEXT: movl $41, %eax
; CHECK-NEXT: adcl $0, %eax
; CHECK-NEXT: retq
%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: testb $1, %dil
; CHECK-NEXT: movl $421, %ecx # imm = 0x1A5
; CHECK-NEXT: movl $42, %eax
; CHECK-NEXT: cmovnel %ecx, %eax
; CHECK-NEXT: retq
%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: testb %dil, %dil
; CHECK-NEXT: movl $421, %ecx # imm = 0x1A5
; CHECK-NEXT: movl $42, %eax
; CHECK-NEXT: cmovnel %ecx, %eax
; CHECK-NEXT: retq
%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: testb $1, %dil
; CHECK-NEXT: movl $421, %ecx # imm = 0x1A5
; CHECK-NEXT: movl $42, %eax
; CHECK-NEXT: cmovnel %ecx, %eax
; CHECK-NEXT: retq
%sel = select i1 %cond, i32 421, i32 42
ret i32 %sel
}
; select (x == 2), 2, (x + 1) --> select (x == 2), x, (x + 1)
[x86] regenerate checks llvm-svn: 284982
2016-10-24 23:43:40 +08:00
define i64 @select_2_or_inc(i64 %x) {
; CHECK-LABEL: select_2_or_inc:
; CHECK: # BB#0:
; CHECK-NEXT: leaq 1(%rdi), %rax
; CHECK-NEXT: cmpq $2, %rdi
; CHECK-NEXT: cmoveq %rdi, %rax
; CHECK-NEXT: retq
Reapply r165661, Patch by Shuxin Yang <shuxin.llvm@gmail.com>. Original message: The attached is the fix to radar://11663049. The optimization can be outlined by following rules: (select (x != c), e, c) -> select (x != c), e, x), (select (x == c), c, e) -> select (x == c), x, e) where the <c> is an integer constant. The reason for this change is that : on x86, conditional-move-from-constant needs two instructions; however, conditional-move-from-register need only one instruction. While the LowerSELECT() sounds to be the most convenient place for this optimization, it turns out to be a bad place. The reason is that by replacing the constant <c> with a symbolic value, it obscure some instruction-combining opportunities which would otherwise be very easy to spot. For that reason, I have to postpone the change to last instruction-combining phase. The change passes the test of "make check-all -C <build-root/test" and "make -C project/test-suite/SingleSource". Original message since r165661: My previous change has a bug: I negated the condition code of a CMOV, and go ahead creating a new CMOV using the *ORIGINAL* condition code. llvm-svn: 166017
2012-10-16 14:28:34 +08:00
%cmp = icmp eq i64 %x, 2
%add = add i64 %x, 1
%retval.0 = select i1 %cmp, i64 2, i64 %add
ret i64 %retval.0
}
[x86] regenerate checks llvm-svn: 284982
2016-10-24 23:43:40 +08:00
[x86] add vector tests for more coverage of D30502; NFC llvm-svn: 296671
2017-03-02 04:31:23 +08:00
define <4 x i32> @sel_constants_add_constant_vec(i1 %cond) {
; CHECK-LABEL: sel_constants_add_constant_vec:
; CHECK: # BB#0:
; CHECK-NEXT: testb $1, %dil
; CHECK-NEXT: jne .LBB22_1
; CHECK-NEXT: # BB#2:
[DAGCombiner] fold binops with constant into select-of-constants This is part of the ongoing attempt to improve select codegen for all targets and select canonicalization in IR (see D24480 for more background). The transform is a subset of what is done in InstCombine's FoldOpIntoSelect(). I first noticed a regression in the x86 avx512-insert-extract.ll tests with a patch that hopes to convert more selects to basic math ops. This appears to be a general missing DAG transform though, so I added tests for all standard binops in rL296621 (PowerPC was chosen semi-randomly; it has scripted FileCheck support, but so do ARM and x86). The poor output for "sel_constants_shl_constant" is tracked with: https://bugs.llvm.org/show_bug.cgi?id=32105 Differential Revision: https://reviews.llvm.org/D30502 llvm-svn: 296699
2017-03-02 06:51:31 +08:00
; CHECK-NEXT: movaps {{.*#+}} xmm0 = [12,13,14,15]
[x86] add vector tests for more coverage of D30502; NFC llvm-svn: 296671
2017-03-02 04:31:23 +08:00
; CHECK-NEXT: retq
; CHECK-NEXT: .LBB22_1:
[DAGCombiner] fold binops with constant into select-of-constants This is part of the ongoing attempt to improve select codegen for all targets and select canonicalization in IR (see D24480 for more background). The transform is a subset of what is done in InstCombine's FoldOpIntoSelect(). I first noticed a regression in the x86 avx512-insert-extract.ll tests with a patch that hopes to convert more selects to basic math ops. This appears to be a general missing DAG transform though, so I added tests for all standard binops in rL296621 (PowerPC was chosen semi-randomly; it has scripted FileCheck support, but so do ARM and x86). The poor output for "sel_constants_shl_constant" is tracked with: https://bugs.llvm.org/show_bug.cgi?id=32105 Differential Revision: https://reviews.llvm.org/D30502 llvm-svn: 296699
2017-03-02 06:51:31 +08:00
; CHECK-NEXT: movaps {{.*#+}} xmm0 = [4294967293,14,4,4]
[x86] add vector tests for more coverage of D30502; NFC llvm-svn: 296671
2017-03-02 04:31:23 +08:00
; CHECK-NEXT: retq
%sel = select i1 %cond, <4 x i32> <i32 -4, i32 12, i32 1, i32 0>, <4 x i32> <i32 11, i32 11, i32 11, i32 11>
%bo = add <4 x i32> %sel, <i32 1, i32 2, i32 3, i32 4>
ret <4 x i32> %bo
}
define <2 x double> @sel_constants_fmul_constant_vec(i1 %cond) {
; CHECK-LABEL: sel_constants_fmul_constant_vec:
; CHECK: # BB#0:
; CHECK-NEXT: testb $1, %dil
; CHECK-NEXT: jne .LBB23_1
; CHECK-NEXT: # BB#2:
[DAGCombiner] fold binops with constant into select-of-constants This is part of the ongoing attempt to improve select codegen for all targets and select canonicalization in IR (see D24480 for more background). The transform is a subset of what is done in InstCombine's FoldOpIntoSelect(). I first noticed a regression in the x86 avx512-insert-extract.ll tests with a patch that hopes to convert more selects to basic math ops. This appears to be a general missing DAG transform though, so I added tests for all standard binops in rL296621 (PowerPC was chosen semi-randomly; it has scripted FileCheck support, but so do ARM and x86). The poor output for "sel_constants_shl_constant" is tracked with: https://bugs.llvm.org/show_bug.cgi?id=32105 Differential Revision: https://reviews.llvm.org/D30502 llvm-svn: 296699
2017-03-02 06:51:31 +08:00
; CHECK-NEXT: movaps {{.*#+}} xmm0 = [1.188300e+02,3.454000e+01]
[x86] add vector tests for more coverage of D30502; NFC llvm-svn: 296671
2017-03-02 04:31:23 +08:00
; CHECK-NEXT: retq
; CHECK-NEXT: .LBB23_1:
[DAGCombiner] fold binops with constant into select-of-constants This is part of the ongoing attempt to improve select codegen for all targets and select canonicalization in IR (see D24480 for more background). The transform is a subset of what is done in InstCombine's FoldOpIntoSelect(). I first noticed a regression in the x86 avx512-insert-extract.ll tests with a patch that hopes to convert more selects to basic math ops. This appears to be a general missing DAG transform though, so I added tests for all standard binops in rL296621 (PowerPC was chosen semi-randomly; it has scripted FileCheck support, but so do ARM and x86). The poor output for "sel_constants_shl_constant" is tracked with: https://bugs.llvm.org/show_bug.cgi?id=32105 Differential Revision: https://reviews.llvm.org/D30502 llvm-svn: 296699
2017-03-02 06:51:31 +08:00
; CHECK-NEXT: movaps {{.*#+}} xmm0 = [-2.040000e+01,3.768000e+01]
[x86] add vector tests for more coverage of D30502; NFC llvm-svn: 296671
2017-03-02 04:31:23 +08:00
; CHECK-NEXT: retq
%sel = select i1 %cond, <2 x double> <double -4.0, double 12.0>, <2 x double> <double 23.3, double 11.0>
%bo = fmul <2 x double> %sel, <double 5.1, double 3.14>
ret <2 x double> %bo
}
[DAGCombiner] avoid assertion when folding binops with opaque constants This bug was introduced with: https://reviews.llvm.org/rL296699 There may be a way to loosen the restriction, but for now just bail out on any opaque constant. The tests show that opacity is target-specific. This goes back to cost calculations in ConstantHoisting based on TTI->getIntImmCost(). llvm-svn: 296768
2017-03-03 01:18:56 +08:00
; 4294967297 = 0x100000001.
; This becomes an opaque constant via ConstantHoisting, so we don't fold it into the select.
define i64 @opaque_constant(i1 %cond, i64 %x) {
; CHECK-LABEL: opaque_constant:
; CHECK: # BB#0:
; CHECK-NEXT: testb $1, %dil
; CHECK-NEXT: movl $23, %ecx
; CHECK-NEXT: movq $-4, %rax
; CHECK-NEXT: cmoveq %rcx, %rax
; CHECK-NEXT: movabsq $4294967297, %rcx # imm = 0x100000001
; CHECK-NEXT: andq %rcx, %rax
; CHECK-NEXT: xorl %edx, %edx
; CHECK-NEXT: cmpq %rcx, %rsi
; CHECK-NEXT: sete %dl
; CHECK-NEXT: subq %rdx, %rax
; CHECK-NEXT: retq
%sel = select i1 %cond, i64 -4, i64 23
%bo = and i64 %sel, 4294967297
%cmp = icmp eq i64 %x, 4294967297
%sext = sext i1 %cmp to i64
%add = add i64 %bo, %sext
ret i64 %add
}