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/avx512-vselect.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

206 lines
7.9 KiB
LLVM
Raw Normal View History

[x86] Fix a failure to select with AVX-512 when the type legalizer manages to form a VSELECT with a non-i1 element type condition. Those are technically allowed in SDAG (at least, the generic type legalization logic will form them and I wouldn't want to try to audit everything te preclude forming them) so we need to be able to lower them. This isn't too hard to implement. We mark VSELECT as custom so we get a chance in C++, add a fast path for i1 conditions to get directly handled by the patterns, and a fallback when we need to manually force the condition to be an i1 that uses the vptestm instruction to turn a non-mask into a mask. This, unsurprisingly, generates awful code. But it at least doesn't crash. This was actually impacting open source packages built with LLVM for AVX-512 in the wild, so quickly landing a patch that at least stops the immediate bleeding. I think I've found where to fix the codegen quality issue, but less confident of that change so separating it out from the thing that doesn't change the result of any existing test case but causes mine to not crash. llvm-svn: 302785
2017-05-11 18:52:16 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mcpu=skx | FileCheck %s --check-prefixes=CHECK,CHECK-SKX
; RUN: llc < %s -mcpu=knl | FileCheck %s --check-prefixes=CHECK,CHECK-KNL
target triple = "x86_64-unknown-unknown"
define <8 x i64> @test1(<8 x i64> %m, <8 x i64> %a, <8 x i64> %b) {
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; CHECK-SKX-LABEL: test1:
; CHECK-SKX: # %bb.0: # %entry
; CHECK-SKX-NEXT: vpsllq $63, %zmm0, %zmm0
; CHECK-SKX-NEXT: vpmovq2m %zmm0, %k1
; CHECK-SKX-NEXT: vpblendmq %zmm1, %zmm2, %zmm0 {%k1}
; CHECK-SKX-NEXT: retq
;
; CHECK-KNL-LABEL: test1:
; CHECK-KNL: # %bb.0: # %entry
; CHECK-KNL-NEXT: vpsllq $63, %zmm0, %zmm0
; CHECK-KNL-NEXT: vptestmq %zmm0, %zmm0, %k1
; CHECK-KNL-NEXT: vpblendmq %zmm1, %zmm2, %zmm0 {%k1}
; CHECK-KNL-NEXT: retq
[x86] Fix a failure to select with AVX-512 when the type legalizer manages to form a VSELECT with a non-i1 element type condition. Those are technically allowed in SDAG (at least, the generic type legalization logic will form them and I wouldn't want to try to audit everything te preclude forming them) so we need to be able to lower them. This isn't too hard to implement. We mark VSELECT as custom so we get a chance in C++, add a fast path for i1 conditions to get directly handled by the patterns, and a fallback when we need to manually force the condition to be an i1 that uses the vptestm instruction to turn a non-mask into a mask. This, unsurprisingly, generates awful code. But it at least doesn't crash. This was actually impacting open source packages built with LLVM for AVX-512 in the wild, so quickly landing a patch that at least stops the immediate bleeding. I think I've found where to fix the codegen quality issue, but less confident of that change so separating it out from the thing that doesn't change the result of any existing test case but causes mine to not crash. llvm-svn: 302785
2017-05-11 18:52:16 +08:00
entry:
%m.trunc = trunc <8 x i64> %m to <8 x i1>
%ret = select <8 x i1> %m.trunc, <8 x i64> %a, <8 x i64> %b
ret <8 x i64> %ret
}
; This is a very contrived test case to trick the legalizer into splitting the
; v16i1 masks in the select during type legalization, and in so doing extend them
; into two v8i64 types. This lets us ensure that the lowering code can handle
; both formulations of vselect. All of this trickery is because we can't
; directly form an SDAG input to the lowering.
define <16 x double> @test2(<16 x float> %x, <16 x float> %y, <16 x double> %a, <16 x double> %b) {
DAG: Fix creating select with wrong condition type This code added in r297930 assumed that it could create a select with a condition type that is just an integer bitcast of the selected type. For AMDGPU any vselect is going to be scalarized (although the vector types are legal), and all select conditions must be i1 (the same as getSetCCResultType). This logic doesn't really make sense to me, but there's never really been a consistent policy in what the select condition mask type is supposed to be. Try to extend the logic for skipping the transform for condition types that aren't setccs. It doesn't seem quite right to me though, but checking conditions that seem more sensible (like whether the vselect is going to be expanded) doesn't work since this seems to depend on that also. llvm-svn: 316554
2017-10-25 15:14:07 +08:00
; CHECK-LABEL: test2:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; CHECK: # %bb.0: # %entry
DAG: Fix creating select with wrong condition type This code added in r297930 assumed that it could create a select with a condition type that is just an integer bitcast of the selected type. For AMDGPU any vselect is going to be scalarized (although the vector types are legal), and all select conditions must be i1 (the same as getSetCCResultType). This logic doesn't really make sense to me, but there's never really been a consistent policy in what the select condition mask type is supposed to be. Try to extend the logic for skipping the transform for condition types that aren't setccs. It doesn't seem quite right to me though, but checking conditions that seem more sensible (like whether the vselect is going to be expanded) doesn't work since this seems to depend on that also. llvm-svn: 316554
2017-10-25 15:14:07 +08:00
; CHECK-NEXT: vxorps %xmm6, %xmm6, %xmm6
; CHECK-NEXT: vcmpltps %zmm0, %zmm6, %k0
; CHECK-NEXT: vcmpltps %zmm6, %zmm1, %k1
; CHECK-NEXT: korw %k1, %k0, %k1
; CHECK-NEXT: vblendmpd %zmm2, %zmm4, %zmm0 {%k1}
; CHECK-NEXT: kshiftrw $8, %k1, %k1
; CHECK-NEXT: vblendmpd %zmm3, %zmm5, %zmm1 {%k1}
; CHECK-NEXT: retq
[x86] Fix a failure to select with AVX-512 when the type legalizer manages to form a VSELECT with a non-i1 element type condition. Those are technically allowed in SDAG (at least, the generic type legalization logic will form them and I wouldn't want to try to audit everything te preclude forming them) so we need to be able to lower them. This isn't too hard to implement. We mark VSELECT as custom so we get a chance in C++, add a fast path for i1 conditions to get directly handled by the patterns, and a fallback when we need to manually force the condition to be an i1 that uses the vptestm instruction to turn a non-mask into a mask. This, unsurprisingly, generates awful code. But it at least doesn't crash. This was actually impacting open source packages built with LLVM for AVX-512 in the wild, so quickly landing a patch that at least stops the immediate bleeding. I think I've found where to fix the codegen quality issue, but less confident of that change so separating it out from the thing that doesn't change the result of any existing test case but causes mine to not crash. llvm-svn: 302785
2017-05-11 18:52:16 +08:00
entry:
%gt.m = fcmp ogt <16 x float> %x, zeroinitializer
%lt.m = fcmp olt <16 x float> %y, zeroinitializer
%m.or = or <16 x i1> %gt.m, %lt.m
%ret = select <16 x i1> %m.or, <16 x double> %a, <16 x double> %b
ret <16 x double> %ret
}
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
define <16 x i64> @test3(<16 x i8> %x, <16 x i64> %a, <16 x i64> %b) {
; CHECK-SKX-LABEL: test3:
; CHECK-SKX: # %bb.0:
[LegalizeTypes][X86] When splitting a vselect for type legalization, don't split a setcc condition if the setcc input is legal and vXi1 conditions are supported Summary: The VSELECT splitting code tries to split a setcc input as well. But on avx512 where mask registers are well supported it should be better to just split the mask and use a single compare. Reviewers: RKSimon, spatel, efriedma Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68359 llvm-svn: 373863
2019-10-07 02:43:03 +08:00
; CHECK-SKX-NEXT: vptestnmb %xmm0, %xmm0, %k1
; CHECK-SKX-NEXT: vpblendmq %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-SKX-NEXT: kshiftrw $8, %k1, %k1
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
; CHECK-SKX-NEXT: vpblendmq %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-SKX-NEXT: retq
;
; CHECK-KNL-LABEL: test3:
; CHECK-KNL: # %bb.0:
; CHECK-KNL-NEXT: vpxor %xmm5, %xmm5, %xmm5
; CHECK-KNL-NEXT: vpcmpeqb %xmm5, %xmm0, %xmm0
; CHECK-KNL-NEXT: vpmovsxbd %xmm0, %zmm0
; CHECK-KNL-NEXT: vptestmd %zmm0, %zmm0, %k1
; CHECK-KNL-NEXT: vpblendmq %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-KNL-NEXT: kshiftrw $8, %k1, %k1
; CHECK-KNL-NEXT: vpblendmq %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-KNL-NEXT: retq
%c = icmp eq <16 x i8> %x, zeroinitializer
%ret = select <16 x i1> %c, <16 x i64> %a, <16 x i64> %b
ret <16 x i64> %ret
}
define <16 x i64> @test4(<16 x i16> %x, <16 x i64> %a, <16 x i64> %b) {
; CHECK-SKX-LABEL: test4:
; CHECK-SKX: # %bb.0:
[LegalizeTypes][X86] When splitting a vselect for type legalization, don't split a setcc condition if the setcc input is legal and vXi1 conditions are supported Summary: The VSELECT splitting code tries to split a setcc input as well. But on avx512 where mask registers are well supported it should be better to just split the mask and use a single compare. Reviewers: RKSimon, spatel, efriedma Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68359 llvm-svn: 373863
2019-10-07 02:43:03 +08:00
; CHECK-SKX-NEXT: vptestnmw %ymm0, %ymm0, %k1
; CHECK-SKX-NEXT: vpblendmq %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-SKX-NEXT: kshiftrw $8, %k1, %k1
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
; CHECK-SKX-NEXT: vpblendmq %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-SKX-NEXT: retq
;
; CHECK-KNL-LABEL: test4:
; CHECK-KNL: # %bb.0:
; CHECK-KNL-NEXT: vpxor %xmm5, %xmm5, %xmm5
; CHECK-KNL-NEXT: vpcmpeqw %ymm5, %ymm0, %ymm0
; CHECK-KNL-NEXT: vpmovsxwd %ymm0, %zmm0
; CHECK-KNL-NEXT: vptestmd %zmm0, %zmm0, %k1
; CHECK-KNL-NEXT: vpblendmq %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-KNL-NEXT: kshiftrw $8, %k1, %k1
; CHECK-KNL-NEXT: vpblendmq %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-KNL-NEXT: retq
%c = icmp eq <16 x i16> %x, zeroinitializer
%ret = select <16 x i1> %c, <16 x i64> %a, <16 x i64> %b
ret <16 x i64> %ret
}
define <16 x i64> @test5(<16 x i32> %x, <16 x i64> %a, <16 x i64> %b) {
[LegalizeTypes][X86] When splitting a vselect for type legalization, don't split a setcc condition if the setcc input is legal and vXi1 conditions are supported Summary: The VSELECT splitting code tries to split a setcc input as well. But on avx512 where mask registers are well supported it should be better to just split the mask and use a single compare. Reviewers: RKSimon, spatel, efriedma Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68359 llvm-svn: 373863
2019-10-07 02:43:03 +08:00
; CHECK-LABEL: test5:
; CHECK: # %bb.0:
; CHECK-NEXT: vptestnmd %zmm0, %zmm0, %k1
; CHECK-NEXT: vpblendmq %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-NEXT: kshiftrw $8, %k1, %k1
; CHECK-NEXT: vpblendmq %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-NEXT: retq
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
%c = icmp eq <16 x i32> %x, zeroinitializer
%ret = select <16 x i1> %c, <16 x i64> %a, <16 x i64> %b
ret <16 x i64> %ret
}
define <32 x i32> @test6(<32 x i8> %x, <32 x i32> %a, <32 x i32> %b) {
; CHECK-SKX-LABEL: test6:
; CHECK-SKX: # %bb.0:
[LegalizeTypes][X86] When splitting a vselect for type legalization, don't split a setcc condition if the setcc input is legal and vXi1 conditions are supported Summary: The VSELECT splitting code tries to split a setcc input as well. But on avx512 where mask registers are well supported it should be better to just split the mask and use a single compare. Reviewers: RKSimon, spatel, efriedma Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68359 llvm-svn: 373863
2019-10-07 02:43:03 +08:00
; CHECK-SKX-NEXT: vptestnmb %ymm0, %ymm0, %k1
; CHECK-SKX-NEXT: vpblendmd %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-SKX-NEXT: kshiftrd $16, %k1, %k1
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
; CHECK-SKX-NEXT: vpblendmd %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-SKX-NEXT: retq
;
; CHECK-KNL-LABEL: test6:
; CHECK-KNL: # %bb.0:
; CHECK-KNL-NEXT: vpxor %xmm5, %xmm5, %xmm5
; CHECK-KNL-NEXT: vpcmpeqb %ymm5, %ymm0, %ymm0
; CHECK-KNL-NEXT: vextracti128 $1, %ymm0, %xmm5
; CHECK-KNL-NEXT: vpmovsxbd %xmm5, %zmm5
; CHECK-KNL-NEXT: vptestmd %zmm5, %zmm5, %k1
; CHECK-KNL-NEXT: vpmovsxbd %xmm0, %zmm0
; CHECK-KNL-NEXT: vptestmd %zmm0, %zmm0, %k2
; CHECK-KNL-NEXT: vpblendmd %zmm1, %zmm3, %zmm0 {%k2}
; CHECK-KNL-NEXT: vpblendmd %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-KNL-NEXT: retq
%c = icmp eq <32 x i8> %x, zeroinitializer
%ret = select <32 x i1> %c, <32 x i32> %a, <32 x i32> %b
ret <32 x i32> %ret
}
define <32 x i32> @test7(<32 x i16> %x, <32 x i32> %a, <32 x i32> %b) {
; CHECK-SKX-LABEL: test7:
; CHECK-SKX: # %bb.0:
[LegalizeTypes][X86] When splitting a vselect for type legalization, don't split a setcc condition if the setcc input is legal and vXi1 conditions are supported Summary: The VSELECT splitting code tries to split a setcc input as well. But on avx512 where mask registers are well supported it should be better to just split the mask and use a single compare. Reviewers: RKSimon, spatel, efriedma Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68359 llvm-svn: 373863
2019-10-07 02:43:03 +08:00
; CHECK-SKX-NEXT: vptestnmw %zmm0, %zmm0, %k1
; CHECK-SKX-NEXT: vpblendmd %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-SKX-NEXT: kshiftrd $16, %k1, %k1
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
; CHECK-SKX-NEXT: vpblendmd %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-SKX-NEXT: retq
;
; CHECK-KNL-LABEL: test7:
; CHECK-KNL: # %bb.0:
; CHECK-KNL-NEXT: vextracti64x4 $1, %zmm0, %ymm5
; CHECK-KNL-NEXT: vpxor %xmm6, %xmm6, %xmm6
; CHECK-KNL-NEXT: vpcmpeqw %ymm6, %ymm5, %ymm5
; CHECK-KNL-NEXT: vpmovsxwd %ymm5, %zmm5
; CHECK-KNL-NEXT: vptestmd %zmm5, %zmm5, %k1
; CHECK-KNL-NEXT: vpcmpeqw %ymm6, %ymm0, %ymm0
; CHECK-KNL-NEXT: vpmovsxwd %ymm0, %zmm0
; CHECK-KNL-NEXT: vptestmd %zmm0, %zmm0, %k2
; CHECK-KNL-NEXT: vpblendmd %zmm1, %zmm3, %zmm0 {%k2}
; CHECK-KNL-NEXT: vpblendmd %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-KNL-NEXT: retq
%c = icmp eq <32 x i16> %x, zeroinitializer
%ret = select <32 x i1> %c, <32 x i32> %a, <32 x i32> %b
ret <32 x i32> %ret
}
define <64 x i16> @test8(<64 x i8> %x, <64 x i16> %a, <64 x i16> %b) {
; CHECK-SKX-LABEL: test8:
; CHECK-SKX: # %bb.0:
[LegalizeTypes][X86] When splitting a vselect for type legalization, don't split a setcc condition if the setcc input is legal and vXi1 conditions are supported Summary: The VSELECT splitting code tries to split a setcc input as well. But on avx512 where mask registers are well supported it should be better to just split the mask and use a single compare. Reviewers: RKSimon, spatel, efriedma Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68359 llvm-svn: 373863
2019-10-07 02:43:03 +08:00
; CHECK-SKX-NEXT: vptestnmb %zmm0, %zmm0, %k1
; CHECK-SKX-NEXT: vpblendmw %zmm1, %zmm3, %zmm0 {%k1}
; CHECK-SKX-NEXT: kshiftrq $32, %k1, %k1
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
; CHECK-SKX-NEXT: vpblendmw %zmm2, %zmm4, %zmm1 {%k1}
; CHECK-SKX-NEXT: retq
;
; CHECK-KNL-LABEL: test8:
; CHECK-KNL: # %bb.0:
; CHECK-KNL-NEXT: pushq %rbp
; CHECK-KNL-NEXT: .cfi_def_cfa_offset 16
; CHECK-KNL-NEXT: .cfi_offset %rbp, -16
; CHECK-KNL-NEXT: movq %rsp, %rbp
; CHECK-KNL-NEXT: .cfi_def_cfa_register %rbp
; CHECK-KNL-NEXT: andq $-32, %rsp
; CHECK-KNL-NEXT: subq $32, %rsp
; CHECK-KNL-NEXT: vextracti64x4 $1, %zmm0, %ymm8
; CHECK-KNL-NEXT: vmovdqa 16(%rbp), %ymm9
; CHECK-KNL-NEXT: vpxor %xmm10, %xmm10, %xmm10
[X86] Teach X86MCInstLower to swap operands of commutable instructions to enable 2-byte VEX encoding. Summary: The 2 source operands commutable instructions are encoded in the VEX.VVVV field and the r/m field of the MODRM byte plus the VEX.B field. The VEX.B field is missing from the 2-byte VEX encoding. If the VEX.VVVV source is 0-7 and the other register is 8-15 we can swap them to avoid needing the VEX.B field. This works as long as the VEX.W, VEX.mmmmm, and VEX.X fields are also not needed. Fixes PR36706. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68550
2019-11-05 11:58:53 +08:00
; CHECK-KNL-NEXT: vpcmpeqb %ymm0, %ymm10, %ymm11
[X86] Add test cases for suboptimal vselect+setcc splitting. If the vselect result type needs to be split, it will try to also try to split the condition if it happens to be a setcc. With avx512 where k-registers are legal, its probably better to just use a kshift to split the mask register. llvm-svn: 373536
2019-10-03 06:35:03 +08:00
; CHECK-KNL-NEXT: vpmovsxbw %xmm11, %ymm0
; CHECK-KNL-NEXT: vpblendvb %ymm0, %ymm1, %ymm5, %ymm0
; CHECK-KNL-NEXT: vextracti128 $1, %ymm11, %xmm1
; CHECK-KNL-NEXT: vpmovsxbw %xmm1, %ymm1
; CHECK-KNL-NEXT: vpblendvb %ymm1, %ymm2, %ymm6, %ymm1
; CHECK-KNL-NEXT: vpcmpeqb %ymm10, %ymm8, %ymm5
; CHECK-KNL-NEXT: vpmovsxbw %xmm5, %ymm2
; CHECK-KNL-NEXT: vpblendvb %ymm2, %ymm3, %ymm7, %ymm2
; CHECK-KNL-NEXT: vextracti128 $1, %ymm5, %xmm3
; CHECK-KNL-NEXT: vpmovsxbw %xmm3, %ymm3
; CHECK-KNL-NEXT: vpblendvb %ymm3, %ymm4, %ymm9, %ymm3
; CHECK-KNL-NEXT: movq %rbp, %rsp
; CHECK-KNL-NEXT: popq %rbp
; CHECK-KNL-NEXT: .cfi_def_cfa %rsp, 8
; CHECK-KNL-NEXT: retq
%c = icmp eq <64 x i8> %x, zeroinitializer
%ret = select <64 x i1> %c, <64 x i16> %a, <64 x i16> %b
ret <64 x i16> %ret
}