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/vector-compare-results.ll

11041 lines
418 KiB
LLVM
Raw Normal View History

[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=SSE --check-prefix=SSE2
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse4.2 | FileCheck %s --check-prefix=SSE --check-prefix=SSE42
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=AVX --check-prefix=AVX1
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx2 | FileCheck %s --check-prefix=AVX --check-prefix=AVX2
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512f | FileCheck %s --check-prefix=AVX --check-prefix=AVX512 --check-prefix=AVX512F
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512dq | FileCheck %s --check-prefix=AVX --check-prefix=AVX512 --check-prefix=AVX512DQ
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512bw | FileCheck %s --check-prefix=AVX --check-prefix=AVX512 --check-prefix=AVX512BW
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
;
; 128-bit vector comparisons
;
define <2 x i1> @test_cmp_v2f64(<2 x double> %a0, <2 x double> %a1) nounwind {
; SSE-LABEL: test_cmp_v2f64:
; SSE: # BB#0:
; SSE-NEXT: cmpltpd %xmm0, %xmm1
; SSE-NEXT: movapd %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v2f64:
; AVX: # BB#0:
; AVX-NEXT: vcmpltpd %xmm0, %xmm1, %xmm0
; AVX-NEXT: retq
%1 = fcmp ogt <2 x double> %a0, %a1
ret <2 x i1> %1
}
define <4 x i1> @test_cmp_v4f32(<4 x float> %a0, <4 x float> %a1) nounwind {
; SSE-LABEL: test_cmp_v4f32:
; SSE: # BB#0:
; SSE-NEXT: cmpltps %xmm0, %xmm1
; SSE-NEXT: movaps %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v4f32:
; AVX: # BB#0:
; AVX-NEXT: vcmpltps %xmm0, %xmm1, %xmm0
; AVX-NEXT: retq
%1 = fcmp ogt <4 x float> %a0, %a1
ret <4 x i1> %1
}
define <2 x i1> @test_cmp_v2i64(<2 x i64> %a0, <2 x i64> %a1) nounwind {
; SSE2-LABEL: test_cmp_v2i64:
; SSE2: # BB#0:
; SSE2-NEXT: movdqa {{.*#+}} xmm2 = [2147483648,0,2147483648,0]
; SSE2-NEXT: pxor %xmm2, %xmm1
; SSE2-NEXT: pxor %xmm2, %xmm0
; SSE2-NEXT: movdqa %xmm0, %xmm2
; SSE2-NEXT: pcmpgtd %xmm1, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm2[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm0
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v2i64:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtq %xmm1, %xmm0
; SSE42-NEXT: retq
;
; AVX-LABEL: test_cmp_v2i64:
; AVX: # BB#0:
; AVX-NEXT: vpcmpgtq %xmm1, %xmm0, %xmm0
; AVX-NEXT: retq
%1 = icmp sgt <2 x i64> %a0, %a1
ret <2 x i1> %1
}
define <4 x i1> @test_cmp_v4i32(<4 x i32> %a0, <4 x i32> %a1) nounwind {
; SSE-LABEL: test_cmp_v4i32:
; SSE: # BB#0:
; SSE-NEXT: pcmpgtd %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v4i32:
; AVX: # BB#0:
; AVX-NEXT: vpcmpgtd %xmm1, %xmm0, %xmm0
; AVX-NEXT: retq
%1 = icmp sgt <4 x i32> %a0, %a1
ret <4 x i1> %1
}
define <8 x i1> @test_cmp_v8i16(<8 x i16> %a0, <8 x i16> %a1) nounwind {
; SSE-LABEL: test_cmp_v8i16:
; SSE: # BB#0:
; SSE-NEXT: pcmpgtw %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v8i16:
; AVX: # BB#0:
; AVX-NEXT: vpcmpgtw %xmm1, %xmm0, %xmm0
; AVX-NEXT: retq
%1 = icmp sgt <8 x i16> %a0, %a1
ret <8 x i1> %1
}
define <16 x i1> @test_cmp_v16i8(<16 x i8> %a0, <16 x i8> %a1) nounwind {
; SSE-LABEL: test_cmp_v16i8:
; SSE: # BB#0:
; SSE-NEXT: pcmpgtb %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v16i8:
; AVX: # BB#0:
; AVX-NEXT: vpcmpgtb %xmm1, %xmm0, %xmm0
; AVX-NEXT: retq
%1 = icmp sgt <16 x i8> %a0, %a1
ret <16 x i1> %1
}
;
; 256-bit vector comparisons
;
define <4 x i1> @test_cmp_v4f64(<4 x double> %a0, <4 x double> %a1) nounwind {
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-LABEL: test_cmp_v4f64:
; SSE: # BB#0:
; SSE-NEXT: cmpltpd %xmm1, %xmm3
; SSE-NEXT: cmpltpd %xmm0, %xmm2
; SSE-NEXT: packsswb %xmm3, %xmm2
; SSE-NEXT: movdqa %xmm2, %xmm0
; SSE-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
;
; AVX1-LABEL: test_cmp_v4f64:
; AVX1: # BB#0:
; AVX1-NEXT: vcmpltpd %ymm0, %ymm1, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v4f64:
; AVX2: # BB#0:
; AVX2-NEXT: vcmpltpd %ymm0, %ymm1, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
; AVX512-LABEL: test_cmp_v4f64:
; AVX512: # BB#0:
; AVX512-NEXT: vcmpltpd %ymm0, %ymm1, %ymm0
; AVX512-NEXT: vpmovqd %zmm0, %ymm0
VirtRegMap: Replace some identity copies with KILL instructions. An identity COPY like this: %AL = COPY %AL, %EAX<imp-def> has no semantic effect, but encodes liveness information: Further users of %EAX only depend on this instruction even though it does not define the full register. Replace the COPY with a KILL instruction in those cases to maintain this liveness information. (This reverts a small part of r238588 but this time adds a comment explaining why a KILL instruction is useful). llvm-svn: 274952
2016-07-09 08:19:07 +08:00
; AVX512-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512-NEXT: vzeroupper
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = fcmp ogt <4 x double> %a0, %a1
ret <4 x i1> %1
}
define <8 x i1> @test_cmp_v8f32(<8 x float> %a0, <8 x float> %a1) nounwind {
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-LABEL: test_cmp_v8f32:
; SSE: # BB#0:
; SSE-NEXT: cmpltps %xmm1, %xmm3
; SSE-NEXT: cmpltps %xmm0, %xmm2
; SSE-NEXT: packsswb %xmm3, %xmm2
; SSE-NEXT: movdqa %xmm2, %xmm0
; SSE-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
;
; AVX1-LABEL: test_cmp_v8f32:
; AVX1: # BB#0:
; AVX1-NEXT: vcmpltps %ymm0, %ymm1, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v8f32:
; AVX2: # BB#0:
; AVX2-NEXT: vcmpltps %ymm0, %ymm1, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
; AVX512-LABEL: test_cmp_v8f32:
; AVX512: # BB#0:
; AVX512-NEXT: vcmpltps %ymm0, %ymm1, %ymm0
; AVX512-NEXT: vpmovdw %zmm0, %ymm0
VirtRegMap: Replace some identity copies with KILL instructions. An identity COPY like this: %AL = COPY %AL, %EAX<imp-def> has no semantic effect, but encodes liveness information: Further users of %EAX only depend on this instruction even though it does not define the full register. Replace the COPY with a KILL instruction in those cases to maintain this liveness information. (This reverts a small part of r238588 but this time adds a comment explaining why a KILL instruction is useful). llvm-svn: 274952
2016-07-09 08:19:07 +08:00
; AVX512-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512-NEXT: vzeroupper
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = fcmp ogt <8 x float> %a0, %a1
ret <8 x i1> %1
}
define <4 x i1> @test_cmp_v4i64(<4 x i64> %a0, <4 x i64> %a1) nounwind {
; SSE2-LABEL: test_cmp_v4i64:
; SSE2: # BB#0:
; SSE2-NEXT: movdqa {{.*#+}} xmm4 = [2147483648,0,2147483648,0]
; SSE2-NEXT: pxor %xmm4, %xmm3
; SSE2-NEXT: pxor %xmm4, %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm5
; SSE2-NEXT: pcmpgtd %xmm3, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm5[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm3
; SSE2-NEXT: pxor %xmm4, %xmm2
; SSE2-NEXT: pxor %xmm4, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: movdqa %xmm0, %xmm1
; SSE2-NEXT: pcmpgtd %xmm2, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm1[0,0,2,2]
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: pcmpeqd %xmm2, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm4, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
; SSE2-NEXT: por %xmm2, %xmm0
; SSE2-NEXT: packsswb %xmm3, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v4i64:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtq %xmm3, %xmm1
; SSE42-NEXT: pcmpgtq %xmm2, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm1, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v4i64:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vpcmpgtq %xmm1, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v4i64:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtq %ymm1, %ymm0, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
; AVX512-LABEL: test_cmp_v4i64:
; AVX512: # BB#0:
; AVX512-NEXT: vpcmpgtq %ymm1, %ymm0, %ymm0
; AVX512-NEXT: vpmovqd %zmm0, %ymm0
VirtRegMap: Replace some identity copies with KILL instructions. An identity COPY like this: %AL = COPY %AL, %EAX<imp-def> has no semantic effect, but encodes liveness information: Further users of %EAX only depend on this instruction even though it does not define the full register. Replace the COPY with a KILL instruction in those cases to maintain this liveness information. (This reverts a small part of r238588 but this time adds a comment explaining why a KILL instruction is useful). llvm-svn: 274952
2016-07-09 08:19:07 +08:00
; AVX512-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512-NEXT: vzeroupper
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <4 x i64> %a0, %a1
ret <4 x i1> %1
}
define <8 x i1> @test_cmp_v8i32(<8 x i32> %a0, <8 x i32> %a1) nounwind {
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-LABEL: test_cmp_v8i32:
; SSE: # BB#0:
; SSE-NEXT: pcmpgtd %xmm3, %xmm1
; SSE-NEXT: pcmpgtd %xmm2, %xmm0
; SSE-NEXT: packsswb %xmm1, %xmm0
; SSE-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
;
; AVX1-LABEL: test_cmp_v8i32:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vpcmpgtd %xmm1, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v8i32:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtd %ymm1, %ymm0, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
; AVX512-LABEL: test_cmp_v8i32:
; AVX512: # BB#0:
; AVX512-NEXT: vpcmpgtd %ymm1, %ymm0, %ymm0
; AVX512-NEXT: vpmovdw %zmm0, %ymm0
VirtRegMap: Replace some identity copies with KILL instructions. An identity COPY like this: %AL = COPY %AL, %EAX<imp-def> has no semantic effect, but encodes liveness information: Further users of %EAX only depend on this instruction even though it does not define the full register. Replace the COPY with a KILL instruction in those cases to maintain this liveness information. (This reverts a small part of r238588 but this time adds a comment explaining why a KILL instruction is useful). llvm-svn: 274952
2016-07-09 08:19:07 +08:00
; AVX512-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512-NEXT: vzeroupper
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <8 x i32> %a0, %a1
ret <8 x i1> %1
}
define <16 x i1> @test_cmp_v16i16(<16 x i16> %a0, <16 x i16> %a1) nounwind {
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-LABEL: test_cmp_v16i16:
; SSE: # BB#0:
; SSE-NEXT: pcmpgtw %xmm3, %xmm1
; SSE-NEXT: pcmpgtw %xmm2, %xmm0
; SSE-NEXT: packsswb %xmm1, %xmm0
; SSE-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
;
; AVX1-LABEL: test_cmp_v16i16:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpcmpgtw %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vpcmpgtw %xmm1, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v16i16:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtw %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v16i16:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtw %ymm1, %ymm0, %ymm0
; AVX512F-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16i16:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtw %ymm1, %ymm0, %ymm0
; AVX512DQ-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16i16:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vpcmpgtw %ymm1, %ymm0, %ymm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <16 x i16> %a0, %a1
ret <16 x i1> %1
}
define <32 x i1> @test_cmp_v32i8(<32 x i8> %a0, <32 x i8> %a1) nounwind {
; SSE2-LABEL: test_cmp_v32i8:
; SSE2: # BB#0:
; SSE2-NEXT: pcmpgtb %xmm2, %xmm0
; SSE2-NEXT: pcmpgtb %xmm3, %xmm1
; SSE2-NEXT: movdqa %xmm1, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, nhaehnle, jyknight Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 282600
2016-09-28 23:50:43 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after upstream changes. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 284151
2016-10-14 03:20:16 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing overly aggressive load-store forwarding optimization. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289221
2016-12-10 00:15:12 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i8:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtb %xmm2, %xmm0
; SSE42-NEXT: pcmpgtb %xmm3, %xmm1
; SSE42-NEXT: pextrb $15, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $14, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $13, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $12, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $11, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $10, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $9, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $8, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $7, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $6, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $5, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $4, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $3, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $2, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $1, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $0, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $15, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $14, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $13, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $12, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $11, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $10, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $9, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $8, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $7, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $6, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $5, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $4, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $3, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $2, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $1, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i8:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpcmpgtb %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vpcmpgtb %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v32i8:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
; AVX512-LABEL: test_cmp_v32i8:
; AVX512: # BB#0:
; AVX512-NEXT: vpcmpgtb %ymm1, %ymm0, %ymm0
; AVX512-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <32 x i8> %a0, %a1
ret <32 x i1> %1
}
;
; 512-bit vector comparisons
;
define <8 x i1> @test_cmp_v8f64(<8 x double> %a0, <8 x double> %a1) nounwind {
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-LABEL: test_cmp_v8f64:
; SSE: # BB#0:
; SSE-NEXT: cmpltpd %xmm3, %xmm7
; SSE-NEXT: cmpltpd %xmm2, %xmm6
; SSE-NEXT: packsswb %xmm7, %xmm6
; SSE-NEXT: cmpltpd %xmm1, %xmm5
; SSE-NEXT: cmpltpd %xmm0, %xmm4
; SSE-NEXT: packsswb %xmm5, %xmm4
; SSE-NEXT: packsswb %xmm6, %xmm4
; SSE-NEXT: movdqa %xmm4, %xmm0
; SSE-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
;
; AVX1-LABEL: test_cmp_v8f64:
; AVX1: # BB#0:
; AVX1-NEXT: vcmpltpd %ymm1, %ymm3, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vcmpltpd %ymm0, %ymm2, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v8f64:
; AVX2: # BB#0:
; AVX2-NEXT: vcmpltpd %ymm1, %ymm3, %ymm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vcmpltpd %ymm0, %ymm2, %ymm0
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-LABEL: test_cmp_v8f64:
; AVX512F: # BB#0:
; AVX512F-NEXT: vcmpltpd %zmm0, %zmm1, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512F-NEXT: vpternlogq $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: vpmovqw %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v8f64:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vcmpltpd %zmm0, %zmm1, %k0
; AVX512DQ-NEXT: vpmovm2q %k0, %zmm0
; AVX512DQ-NEXT: vpmovqw %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v8f64:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vcmpltpd %zmm0, %zmm1, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512BW-NEXT: vpternlogq $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: vpmovqw %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = fcmp ogt <8 x double> %a0, %a1
ret <8 x i1> %1
}
define <16 x i1> @test_cmp_v16f32(<16 x float> %a0, <16 x float> %a1) nounwind {
; SSE-LABEL: test_cmp_v16f32:
; SSE: # BB#0:
; SSE-NEXT: cmpltps %xmm3, %xmm7
; SSE-NEXT: cmpltps %xmm2, %xmm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm7, %xmm6
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE-NEXT: cmpltps %xmm1, %xmm5
; SSE-NEXT: cmpltps %xmm0, %xmm4
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm5, %xmm4
; SSE-NEXT: packsswb %xmm6, %xmm4
; SSE-NEXT: movdqa %xmm4, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE-NEXT: retq
;
; AVX1-LABEL: test_cmp_v16f32:
; AVX1: # BB#0:
; AVX1-NEXT: vcmpltps %ymm1, %ymm3, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v16f32:
; AVX2: # BB#0:
; AVX2-NEXT: vcmpltps %ymm1, %ymm3, %ymm1
; AVX2-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-LABEL: test_cmp_v16f32:
; AVX512F: # BB#0:
; AVX512F-NEXT: vcmpltps %zmm0, %zmm1, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16f32:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vcmpltps %zmm0, %zmm1, %k0
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16f32:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vcmpltps %zmm0, %zmm1, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512BW-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = fcmp ogt <16 x float> %a0, %a1
ret <16 x i1> %1
}
define <8 x i1> @test_cmp_v8i64(<8 x i64> %a0, <8 x i64> %a1) nounwind {
; SSE2-LABEL: test_cmp_v8i64:
; SSE2: # BB#0:
; SSE2-NEXT: movdqa {{.*#+}} xmm8 = [2147483648,0,2147483648,0]
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm3, %xmm9
; SSE2-NEXT: pcmpgtd %xmm7, %xmm9
; SSE2-NEXT: pshufd {{.*#+}} xmm10 = xmm9[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm7, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm10, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm9[1,1,3,3]
; SSE2-NEXT: por %xmm3, %xmm7
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm6
; SSE2-NEXT: pxor %xmm8, %xmm2
; SSE2-NEXT: movdqa %xmm2, %xmm3
; SSE2-NEXT: pcmpgtd %xmm6, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm3[0,0,2,2]
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: pcmpeqd %xmm6, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm2[1,1,3,3]
; SSE2-NEXT: pand %xmm9, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
; SSE2-NEXT: por %xmm6, %xmm2
; SSE2-NEXT: packsswb %xmm7, %xmm2
; SSE2-NEXT: pxor %xmm8, %xmm5
; SSE2-NEXT: pxor %xmm8, %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm3
; SSE2-NEXT: pcmpgtd %xmm5, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm3[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm5, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[1,1,3,3]
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: por %xmm1, %xmm3
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: movdqa %xmm0, %xmm1
; SSE2-NEXT: pcmpgtd %xmm4, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm1[0,0,2,2]
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: pcmpeqd %xmm4, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm4
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: por %xmm4, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: packsswb %xmm3, %xmm0
; SSE2-NEXT: packsswb %xmm2, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v8i64:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtq %xmm7, %xmm3
; SSE42-NEXT: pcmpgtq %xmm6, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm3, %xmm2
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: pcmpgtq %xmm5, %xmm1
; SSE42-NEXT: pcmpgtq %xmm4, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm1, %xmm0
; SSE42-NEXT: packsswb %xmm2, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v8i64:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtq %xmm4, %xmm5, %xmm4
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm4, %xmm1, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm4
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm4, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm2, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v8i64:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtq %ymm3, %ymm1, %ymm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-LABEL: test_cmp_v8i64:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtq %zmm1, %zmm0, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512F-NEXT: vpternlogq $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: vpmovqw %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v8i64:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtq %zmm1, %zmm0, %k0
; AVX512DQ-NEXT: vpmovm2q %k0, %zmm0
; AVX512DQ-NEXT: vpmovqw %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v8i64:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vpcmpgtq %zmm1, %zmm0, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512BW-NEXT: vpternlogq $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: vpmovqw %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <8 x i64> %a0, %a1
ret <8 x i1> %1
}
define <16 x i1> @test_cmp_v16i32(<16 x i32> %a0, <16 x i32> %a1) nounwind {
; SSE-LABEL: test_cmp_v16i32:
; SSE: # BB#0:
; SSE-NEXT: pcmpgtd %xmm7, %xmm3
; SSE-NEXT: pcmpgtd %xmm6, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm3, %xmm2
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE-NEXT: pcmpgtd %xmm5, %xmm1
; SSE-NEXT: pcmpgtd %xmm4, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm1, %xmm0
; SSE-NEXT: packsswb %xmm2, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE-NEXT: retq
;
; AVX1-LABEL: test_cmp_v16i32:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtd %xmm4, %xmm5, %xmm4
; AVX1-NEXT: vpcmpgtd %xmm3, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm4, %xmm1, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm4
; AVX1-NEXT: vpcmpgtd %xmm3, %xmm4, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm2, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v16i32:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtd %ymm3, %ymm1, %ymm1
; AVX2-NEXT: vpcmpgtd %ymm2, %ymm0, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-LABEL: test_cmp_v16i32:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtd %zmm1, %zmm0, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16i32:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtd %zmm1, %zmm0, %k0
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16i32:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vpcmpgtd %zmm1, %zmm0, %k1
[AVX-512] Add patterns to use a zero masked VPTERNLOG instruction for vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. llvm-svn: 291415
2017-01-09 10:44:34 +08:00
; AVX512BW-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[AVX-512] If avx512dq is available use vpmovm2d/vpmovm2q instead of vselect of zeroes/ones when handling sign extends of i1 without VLX. llvm-svn: 291402
2017-01-09 05:32:30 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <16 x i32> %a0, %a1
ret <16 x i1> %1
}
define <32 x i1> @test_cmp_v32i16(<32 x i16> %a0, <32 x i16> %a1) nounwind {
; SSE2-LABEL: test_cmp_v32i16:
; SSE2: # BB#0:
; SSE2-NEXT: pcmpgtw %xmm5, %xmm1
; SSE2-NEXT: movdqa {{.*#+}} xmm5 = [255,255,255,255,255,255,255,255]
; SSE2-NEXT: pand %xmm5, %xmm1
; SSE2-NEXT: pcmpgtw %xmm4, %xmm0
; SSE2-NEXT: pand %xmm5, %xmm0
; SSE2-NEXT: packuswb %xmm1, %xmm0
; SSE2-NEXT: pcmpgtw %xmm7, %xmm3
; SSE2-NEXT: pand %xmm5, %xmm3
; SSE2-NEXT: pcmpgtw %xmm6, %xmm2
; SSE2-NEXT: pand %xmm5, %xmm2
; SSE2-NEXT: packuswb %xmm3, %xmm2
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, nhaehnle, jyknight Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 282600
2016-09-28 23:50:43 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after upstream changes. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 284151
2016-10-14 03:20:16 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing overly aggressive load-store forwarding optimization. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289221
2016-12-10 00:15:12 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i16:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtw %xmm4, %xmm0
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtw %xmm5, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: pcmpgtw %xmm6, %xmm2
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtw %xmm7, %xmm3
; SSE42-NEXT: pextrb $14, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm3, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm2, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $0, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm1, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm0, %eax
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i16:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtw %xmm4, %xmm5, %xmm4
; AVX1-NEXT: vpcmpgtw %xmm3, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm4, %xmm1, %xmm1
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm4
; AVX1-NEXT: vpcmpgtw %xmm3, %xmm4, %xmm3
; AVX1-NEXT: vpcmpgtw %xmm2, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v32i16:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtw %ymm3, %ymm1, %ymm1
; AVX2-NEXT: vpcmpgtw %ymm2, %ymm0, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v32i16:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtw %ymm2, %ymm0, %ymm0
; AVX512F-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vpcmpgtw %ymm3, %ymm1, %ymm1
; AVX512F-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v32i16:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtw %ymm2, %ymm0, %ymm0
; AVX512DQ-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vpcmpgtw %ymm3, %ymm1, %ymm1
; AVX512DQ-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v32i16:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vpcmpgtw %zmm1, %zmm0, %k1
; AVX512BW-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0
; AVX512BW-NEXT: vmovdqu16 %zmm0, %zmm0 {%k1} {z}
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <32 x i16> %a0, %a1
ret <32 x i1> %1
}
define <64 x i1> @test_cmp_v64i8(<64 x i8> %a0, <64 x i8> %a1) nounwind {
; SSE2-LABEL: test_cmp_v64i8:
; SSE2: # BB#0:
; SSE2-NEXT: pcmpgtb %xmm4, %xmm0
; SSE2-NEXT: pcmpgtb %xmm5, %xmm1
; SSE2-NEXT: pcmpgtb %xmm6, %xmm2
; SSE2-NEXT: pcmpgtb %xmm7, %xmm3
; SSE2-NEXT: movdqa %xmm3, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
; SSE2-NEXT: movdqa %xmm1, -{{[0-9]+}}(%rsp)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 4(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v64i8:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtb %xmm4, %xmm0
; SSE42-NEXT: pcmpgtb %xmm5, %xmm1
; SSE42-NEXT: pcmpgtb %xmm6, %xmm2
; SSE42-NEXT: pcmpgtb %xmm7, %xmm3
; SSE42-NEXT: pextrb $15, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $14, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $13, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $12, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $11, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $10, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $9, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $8, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $7, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $6, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $5, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $4, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $3, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $2, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $1, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $0, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $15, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $14, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $13, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $12, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $11, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $10, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $9, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $8, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $7, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $6, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $5, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $4, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $3, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $2, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $1, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $0, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $15, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $14, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $13, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $12, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $11, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $10, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $9, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $8, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $7, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $6, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $5, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $4, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $3, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $2, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $1, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $0, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $15, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $14, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $13, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $12, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $11, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $10, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $9, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $8, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $7, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $6, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $5, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $4, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $3, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $2, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $1, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v64i8:
; AVX1: # BB#0:
; AVX1-NEXT: vpcmpgtb %xmm2, %xmm0, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpcmpgtb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpcmpgtb %xmm3, %xmm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
; AVX1-NEXT: vpcmpgtb %xmm3, %xmm1, %xmm1
; AVX1-NEXT: vpextrb $15, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $14, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $13, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $12, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $11, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $10, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $9, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $8, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $7, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $6, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $5, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $4, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $3, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $2, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $1, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $0, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $15, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $14, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $13, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $12, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $11, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $10, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $9, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $8, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $7, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $6, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $5, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $4, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $3, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $2, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $1, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $0, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: movq %rdi, %rax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v64i8:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpcmpgtb %ymm3, %ymm1, %ymm1
; AVX2-NEXT: vextracti128 $1, %ymm1, %xmm2
; AVX2-NEXT: vpextrb $15, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $15, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpextrb $15, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $14, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $13, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $12, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $11, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $10, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $9, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $8, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $7, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $6, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $5, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $4, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $3, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $2, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $0, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $15, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $14, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $13, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $12, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $11, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $10, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $9, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $8, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $7, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $6, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $5, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $4, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $3, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $2, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $1, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $0, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: movq %rdi, %rax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v64i8:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtb %ymm3, %ymm1, %ymm4
; AVX512F-NEXT: vpcmpgtb %ymm2, %ymm0, %ymm0
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX512F-NEXT: vextracti128 $1, %ymm4, %xmm3
; AVX512F-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
; AVX512F-NEXT: vmovdqa %xmm4, %xmm2
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v64i8:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtb %ymm3, %ymm1, %ymm4
; AVX512DQ-NEXT: vpcmpgtb %ymm2, %ymm0, %ymm0
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX512DQ-NEXT: vextracti128 $1, %ymm4, %xmm3
; AVX512DQ-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
; AVX512DQ-NEXT: vmovdqa %xmm4, %xmm2
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v64i8:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vpcmpgtb %zmm1, %zmm0, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
; AVX512BW-NEXT: retq
[X86][SSE] Test the legalization of vector comparison results We are currently doing a REALLY bad job of packing results of vector comparisons into the legalized <X x i1> result equivalents - a mixture of PACKSS/PMOVMSKB would be much better here. llvm-svn: 264867
2016-03-30 21:55:00 +08:00
%1 = icmp sgt <64 x i8> %a0, %a1
ret <64 x i1> %1
}
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
;
; 1024-bit vector comparisons
;
define <16 x i1> @test_cmp_v16f64(<16 x double> %a0, <16 x double> %a1) nounwind {
; SSE-LABEL: test_cmp_v16f64:
; SSE: # BB#0:
; SSE-NEXT: movapd %xmm0, %xmm8
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm11
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm10
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm12
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm9
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm13
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm14
; SSE-NEXT: movapd {{[0-9]+}}(%rsp), %xmm15
; SSE-NEXT: cmpltpd %xmm7, %xmm15
; SSE-NEXT: cmpltpd %xmm6, %xmm14
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm15, %xmm14
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE-NEXT: cmpltpd %xmm5, %xmm13
; SSE-NEXT: cmpltpd %xmm4, %xmm9
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm13, %xmm9
; SSE-NEXT: packsswb %xmm14, %xmm9
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE-NEXT: cmpltpd %xmm3, %xmm12
; SSE-NEXT: cmpltpd %xmm2, %xmm10
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm12, %xmm10
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE-NEXT: cmpltpd %xmm1, %xmm11
; SSE-NEXT: cmpltpd %xmm8, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE-NEXT: packsswb %xmm11, %xmm0
; SSE-NEXT: packsswb %xmm10, %xmm0
; SSE-NEXT: packsswb %xmm9, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE-NEXT: retq
;
; AVX1-LABEL: test_cmp_v16f64:
; AVX1: # BB#0:
; AVX1-NEXT: vcmpltpd %ymm3, %ymm7, %ymm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm7
; AVX1-NEXT: vpacksswb %xmm7, %xmm3, %xmm3
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vcmpltpd %ymm2, %ymm6, %ymm2
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm6, %xmm2, %xmm2
; AVX1-NEXT: vpacksswb %xmm3, %xmm2, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vcmpltpd %ymm1, %ymm5, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vcmpltpd %ymm0, %ymm4, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v16f64:
; AVX2: # BB#0:
; AVX2-NEXT: vcmpltpd %ymm3, %ymm7, %ymm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vcmpltpd %ymm2, %ymm6, %ymm2
; AVX2-NEXT: vpacksswb %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vcmpltpd %ymm1, %ymm5, %ymm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vcmpltpd %ymm0, %ymm4, %ymm0
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v16f64:
; AVX512F: # BB#0:
; AVX512F-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512F-NEXT: vextractf32x4 $3, %zmm0, %xmm5
; AVX512F-NEXT: xorl %eax, %eax
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movq $-1, %rcx
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512F-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512F-NEXT: vextractf32x4 $2, %zmm0, %xmm6
; AVX512F-NEXT: vucomisd %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm7
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm6[1,0]
; AVX512F-NEXT: vucomisd %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm7[0],xmm5[0]
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512F-NEXT: vextractf32x4 $1, %zmm2, %xmm5
; AVX512F-NEXT: vextractf32x4 $1, %zmm0, %xmm6
; AVX512F-NEXT: vucomisd %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm7
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm6[1,0]
; AVX512F-NEXT: vucomisd %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm7[0],xmm5[0]
; AVX512F-NEXT: vucomisd %xmm2, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vucomisd %xmm2, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm6[0],xmm0[0]
; AVX512F-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm0
; AVX512F-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512F-NEXT: vextractf32x4 $3, %zmm1, %xmm4
; AVX512F-NEXT: vucomisd %xmm2, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vucomisd %xmm2, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512F-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512F-NEXT: vextractf32x4 $2, %zmm1, %xmm5
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512F-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512F-NEXT: vextractf32x4 $1, %zmm3, %xmm4
; AVX512F-NEXT: vextractf32x4 $1, %zmm1, %xmm5
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512F-NEXT: vucomisd %xmm3, %xmm1
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm3 = xmm3[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512F-NEXT: vucomisd %xmm3, %xmm1
; AVX512F-NEXT: cmovaq %rcx, %rax
; AVX512F-NEXT: vmovq %rax, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512F-NEXT: vpmovqd %zmm1, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16f64:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm2, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm0, %xmm5
; AVX512DQ-NEXT: xorl %eax, %eax
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movq $-1, %rcx
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm2, %xmm5
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm0, %xmm6
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm7
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm6[1,0]
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm7[0],xmm5[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm2, %xmm5
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm0, %xmm6
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm7
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm6[1,0]
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm7[0],xmm5[0]
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm6[0],xmm0[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm0
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm3, %xmm2
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm1, %xmm4
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm3, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm1, %xmm5
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm3, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm1, %xmm5
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512DQ-NEXT: vucomisd %xmm3, %xmm1
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm3 = xmm3[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512DQ-NEXT: vucomisd %xmm3, %xmm1
; AVX512DQ-NEXT: cmovaq %rcx, %rax
; AVX512DQ-NEXT: vmovq %rax, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512DQ-NEXT: vpmovqd %zmm1, %ymm1
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm1, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16f64:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vextractf32x4 $3, %zmm0, %xmm5
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movq $-1, %rcx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vextractf32x4 $2, %zmm0, %xmm6
; AVX512BW-NEXT: vucomisd %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm7
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm6[1,0]
; AVX512BW-NEXT: vucomisd %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm7[0],xmm5[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512BW-NEXT: vextractf32x4 $1, %zmm2, %xmm5
; AVX512BW-NEXT: vextractf32x4 $1, %zmm0, %xmm6
; AVX512BW-NEXT: vucomisd %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm7
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm6[1,0]
; AVX512BW-NEXT: vucomisd %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm7[0],xmm5[0]
; AVX512BW-NEXT: vucomisd %xmm2, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512BW-NEXT: vucomisd %xmm2, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm6[0],xmm0[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm0
; AVX512BW-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vextractf32x4 $3, %zmm1, %xmm4
; AVX512BW-NEXT: vucomisd %xmm2, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vucomisd %xmm2, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vextractf32x4 $2, %zmm1, %xmm5
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512BW-NEXT: vextractf32x4 $1, %zmm3, %xmm4
; AVX512BW-NEXT: vextractf32x4 $1, %zmm1, %xmm5
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm6[0],xmm4[0]
; AVX512BW-NEXT: vucomisd %xmm3, %xmm1
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm3 = xmm3[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512BW-NEXT: vucomisd %xmm3, %xmm1
; AVX512BW-NEXT: cmovaq %rcx, %rax
; AVX512BW-NEXT: vmovq %rax, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512BW-NEXT: vpmovqd %zmm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
%1 = fcmp ogt <16 x double> %a0, %a1
ret <16 x i1> %1
}
define <32 x i1> @test_cmp_v32f32(<32 x float> %a0, <32 x float> %a1) nounwind {
; SSE2-LABEL: test_cmp_v32f32:
; SSE2: # BB#0:
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm8
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm9
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm10
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm11
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm12
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm13
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm14
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm15
; SSE2-NEXT: cmpltps %xmm3, %xmm15
; SSE2-NEXT: pshuflw {{.*#+}} xmm3 = xmm15[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm3 = xmm3[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[0,2,2,3]
; SSE2-NEXT: cmpltps %xmm2, %xmm14
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm14[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; SSE2-NEXT: psllw $15, %xmm2
; SSE2-NEXT: psraw $15, %xmm2
; SSE2-NEXT: movdqa {{.*#+}} xmm3 = [255,255,255,255,255,255,255,255]
; SSE2-NEXT: pand %xmm3, %xmm2
; SSE2-NEXT: cmpltps %xmm1, %xmm13
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm13[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: cmpltps %xmm0, %xmm12
; SSE2-NEXT: pshuflw {{.*#+}} xmm0 = xmm12[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: psllw $15, %xmm0
; SSE2-NEXT: psraw $15, %xmm0
; SSE2-NEXT: pand %xmm3, %xmm0
; SSE2-NEXT: packuswb %xmm2, %xmm0
; SSE2-NEXT: cmpltps %xmm7, %xmm11
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm11[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: cmpltps %xmm6, %xmm10
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm10[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
; SSE2-NEXT: psllw $15, %xmm2
; SSE2-NEXT: psraw $15, %xmm2
; SSE2-NEXT: pand %xmm3, %xmm2
; SSE2-NEXT: cmpltps %xmm5, %xmm9
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm9[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: cmpltps %xmm4, %xmm8
; SSE2-NEXT: pshuflw {{.*#+}} xmm4 = xmm8[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm4 = xmm4[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm4[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm1[0]
; SSE2-NEXT: psllw $15, %xmm4
; SSE2-NEXT: psraw $15, %xmm4
; SSE2-NEXT: pand %xmm3, %xmm4
; SSE2-NEXT: packuswb %xmm2, %xmm4
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, nhaehnle, jyknight Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 282600
2016-09-28 23:50:43 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after upstream changes. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 284151
2016-10-14 03:20:16 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing overly aggressive load-store forwarding optimization. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289221
2016-12-10 00:15:12 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32f32:
; SSE42: # BB#0:
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm11
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm12
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm10
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm13
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm9
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm14
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm8
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm15
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltps %xmm1, %xmm15
; SSE42-NEXT: movdqa {{.*#+}} xmm1 = [0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; SSE42-NEXT: pshufb %xmm1, %xmm15
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: cmpltps %xmm0, %xmm8
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pshufb %xmm1, %xmm8
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm8 = xmm8[0],xmm15[0]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: psllw $15, %xmm8
; SSE42-NEXT: psraw $15, %xmm8
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltps %xmm3, %xmm14
; SSE42-NEXT: pshufb %xmm1, %xmm14
; SSE42-NEXT: cmpltps %xmm2, %xmm9
; SSE42-NEXT: pshufb %xmm1, %xmm9
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm14[0]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: psllw $15, %xmm9
; SSE42-NEXT: psraw $15, %xmm9
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltps %xmm5, %xmm13
; SSE42-NEXT: pshufb %xmm1, %xmm13
; SSE42-NEXT: cmpltps %xmm4, %xmm10
; SSE42-NEXT: pshufb %xmm1, %xmm10
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm10 = xmm10[0],xmm13[0]
; SSE42-NEXT: psllw $15, %xmm10
; SSE42-NEXT: psraw $15, %xmm10
; SSE42-NEXT: cmpltps %xmm7, %xmm12
; SSE42-NEXT: pshufb %xmm1, %xmm12
; SSE42-NEXT: cmpltps %xmm6, %xmm11
; SSE42-NEXT: pshufb %xmm1, %xmm11
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm11 = xmm11[0],xmm12[0]
; SSE42-NEXT: psllw $15, %xmm11
; SSE42-NEXT: psraw $15, %xmm11
; SSE42-NEXT: pextrb $14, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm11, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm10, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm9, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm8, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm8, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32f32:
; AVX1: # BB#0:
; AVX1-NEXT: vcmpltps %ymm3, %ymm7, %ymm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm7
; AVX1-NEXT: vpacksswb %xmm7, %xmm3, %xmm3
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vcmpltps %ymm2, %ymm6, %ymm2
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm6, %xmm2, %xmm2
; AVX1-NEXT: vpacksswb %xmm3, %xmm2, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vcmpltps %ymm1, %ymm5, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vcmpltps %ymm0, %ymm4, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v32f32:
; AVX2: # BB#0:
; AVX2-NEXT: vcmpltps %ymm3, %ymm7, %ymm3
; AVX2-NEXT: vcmpltps %ymm2, %ymm6, %ymm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vcmpltps %ymm1, %ymm5, %ymm1
; AVX2-NEXT: vcmpltps %ymm0, %ymm4, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v32f32:
; AVX512F: # BB#0:
; AVX512F-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm5 = xmm4[1,1,3,3]
; AVX512F-NEXT: vextractf32x4 $3, %zmm0, %xmm6
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm7 = xmm6[1,1,3,3]
; AVX512F-NEXT: xorl %eax, %eax
; AVX512F-NEXT: vucomiss %xmm5, %xmm7
; AVX512F-NEXT: movl $-1, %ecx
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm4, %xmm6
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm5
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm5, %xmm8
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm7 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm6[1,0]
; AVX512F-NEXT: vucomiss %xmm7, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm8, %xmm5
; AVX512F-NEXT: vpermilps {{.*#+}} xmm4 = xmm4[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm6 = xmm6[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm4, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm5, %xmm8
; AVX512F-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512F-NEXT: vextractf32x4 $2, %zmm0, %xmm7
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm4 = xmm7[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm6, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm5, %xmm7
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm4
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm4, %xmm9
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm5[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm7[1,0]
; AVX512F-NEXT: vucomiss %xmm6, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm9, %xmm4
; AVX512F-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm6 = xmm7[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vinserti128 $1, %xmm8, %ymm4, %ymm8
; AVX512F-NEXT: vextractf32x4 $1, %zmm2, %xmm5
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512F-NEXT: vextractf32x4 $1, %zmm0, %xmm7
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm4 = xmm7[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm6, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm5, %xmm7
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm4
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm4, %xmm9
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm5[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm7[1,0]
; AVX512F-NEXT: vucomiss %xmm6, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm9, %xmm4
; AVX512F-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm6 = xmm7[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm5 = xmm2[1,1,3,3]
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm6 = xmm0[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm2, %xmm0
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm5
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm2[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm7 = xmm0[1,0]
; AVX512F-NEXT: vucomiss %xmm6, %xmm7
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm2, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm5, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm8
; AVX512F-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm4 = xmm2[1,1,3,3]
; AVX512F-NEXT: vextractf32x4 $3, %zmm1, %xmm5
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm4, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm2, %xmm5
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm4
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm2[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm7 = xmm5[1,0]
; AVX512F-NEXT: vucomiss %xmm6, %xmm7
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm2, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm4, %xmm2
; AVX512F-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm5 = xmm4[1,1,3,3]
; AVX512F-NEXT: vextractf32x4 $2, %zmm1, %xmm6
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm7 = xmm6[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm5, %xmm7
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm4, %xmm6
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm5
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm7 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm6[1,0]
; AVX512F-NEXT: vucomiss %xmm7, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm5, %xmm0
; AVX512F-NEXT: vpermilps {{.*#+}} xmm4 = xmm4[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm5 = xmm6[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm0, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm2, %ymm0, %ymm2
; AVX512F-NEXT: vextractf32x4 $1, %zmm3, %xmm0
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm4 = xmm0[1,1,3,3]
; AVX512F-NEXT: vextractf32x4 $1, %zmm1, %xmm5
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm4, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm0, %xmm5
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm4
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm0[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm7 = xmm5[1,0]
; AVX512F-NEXT: vucomiss %xmm6, %xmm7
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm0, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm4, %xmm0
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm4 = xmm3[1,1,3,3]
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm5 = xmm1[1,1,3,3]
; AVX512F-NEXT: vucomiss %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vucomiss %xmm3, %xmm1
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmoval %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm4
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm3[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm6 = xmm1[1,0]
; AVX512F-NEXT: vucomiss %xmm5, %xmm6
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmoval %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512F-NEXT: vpermilps {{.*#+}} xmm3 = xmm3[3,1,2,3]
; AVX512F-NEXT: vpermilps {{.*#+}} xmm1 = xmm1[3,1,2,3]
; AVX512F-NEXT: vucomiss %xmm3, %xmm1
; AVX512F-NEXT: cmoval %ecx, %eax
; AVX512F-NEXT: vpinsrd $3, %eax, %xmm4, %xmm1
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm8, %ymm0
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v32f32:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm5 = xmm4[1,1,3,3]
; AVX512DQ-NEXT: vextractf32x4 $3, %zmm0, %xmm6
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm7 = xmm6[1,1,3,3]
; AVX512DQ-NEXT: xorl %eax, %eax
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm7
; AVX512DQ-NEXT: movl $-1, %ecx
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm6
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm5
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm5, %xmm8
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm7 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm6[1,0]
; AVX512DQ-NEXT: vucomiss %xmm7, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm8, %xmm5
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm4 = xmm4[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm6 = xmm6[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm5, %xmm8
; AVX512DQ-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512DQ-NEXT: vextractf32x4 $2, %zmm0, %xmm7
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm4 = xmm7[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm7
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm4
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm4, %xmm9
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm5[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm7[1,0]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm9, %xmm4
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm6 = xmm7[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vinserti128 $1, %xmm8, %ymm4, %ymm8
; AVX512DQ-NEXT: vextractf32x4 $1, %zmm2, %xmm5
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512DQ-NEXT: vextractf32x4 $1, %zmm0, %xmm7
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm4 = xmm7[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm7
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm4
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm4, %xmm9
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm5[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm7[1,0]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm9, %xmm4
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm6 = xmm7[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm5 = xmm2[1,1,3,3]
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm6 = xmm0[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm2, %xmm0
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm5
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm2[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm7 = xmm0[1,0]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm7
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm2, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm5, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm0, %ymm0
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm8, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm8
; AVX512DQ-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm4 = xmm2[1,1,3,3]
; AVX512DQ-NEXT: vextractf32x4 $3, %zmm1, %xmm5
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm2, %xmm5
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm4
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm2[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm7 = xmm5[1,0]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm7
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm2, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm4, %xmm2
; AVX512DQ-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm5 = xmm4[1,1,3,3]
; AVX512DQ-NEXT: vextractf32x4 $2, %zmm1, %xmm6
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm7 = xmm6[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm7
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm6
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm5
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm7 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm0 = xmm6[1,0]
; AVX512DQ-NEXT: vucomiss %xmm7, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm5, %xmm0
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm4 = xmm4[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm5 = xmm6[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm0, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm2, %ymm0, %ymm2
; AVX512DQ-NEXT: vextractf32x4 $1, %zmm3, %xmm0
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm4 = xmm0[1,1,3,3]
; AVX512DQ-NEXT: vextractf32x4 $1, %zmm1, %xmm5
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm0, %xmm5
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm4
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm0[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm7 = xmm5[1,0]
; AVX512DQ-NEXT: vucomiss %xmm6, %xmm7
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm0, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm4, %xmm0
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm4 = xmm3[1,1,3,3]
; AVX512DQ-NEXT: vmovshdup {{.*#+}} xmm5 = xmm1[1,1,3,3]
; AVX512DQ-NEXT: vucomiss %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vucomiss %xmm3, %xmm1
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmoval %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm4
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm3[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm6 = xmm1[1,0]
; AVX512DQ-NEXT: vucomiss %xmm5, %xmm6
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmoval %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm3 = xmm3[3,1,2,3]
; AVX512DQ-NEXT: vpermilps {{.*#+}} xmm1 = xmm1[3,1,2,3]
; AVX512DQ-NEXT: vucomiss %xmm3, %xmm1
; AVX512DQ-NEXT: cmoval %ecx, %eax
; AVX512DQ-NEXT: vpinsrd $3, %eax, %xmm4, %xmm1
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm2, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm8, %ymm0
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v32f32:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm5 = xmm4[1,1,3,3]
; AVX512BW-NEXT: vextractf32x4 $3, %zmm0, %xmm6
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm7 = xmm6[1,1,3,3]
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: vucomiss %xmm5, %xmm7
; AVX512BW-NEXT: movl $-1, %ecx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm4, %xmm6
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm5, %xmm8
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm7 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm6[1,0]
; AVX512BW-NEXT: vucomiss %xmm7, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm8, %xmm5
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm4 = xmm4[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm6 = xmm6[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm4, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm5, %xmm8
; AVX512BW-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm0, %xmm7
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm4 = xmm7[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm5, %xmm7
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm4
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm4, %xmm9
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm5[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm7[1,0]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm9, %xmm4
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm6 = xmm7[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vinserti128 $1, %xmm8, %ymm4, %ymm8
; AVX512BW-NEXT: vextractf32x4 $1, %zmm2, %xmm5
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512BW-NEXT: vextractf32x4 $1, %zmm0, %xmm7
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm4 = xmm7[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm5, %xmm7
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm4
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm4, %xmm9
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm5[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm7[1,0]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm9, %xmm4
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm6 = xmm7[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm5 = xmm2[1,1,3,3]
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm6 = xmm0[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm2, %xmm0
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm2[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm7 = xmm0[1,0]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm7
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm2, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm5, %xmm0
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm8
; AVX512BW-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm4 = xmm2[1,1,3,3]
; AVX512BW-NEXT: vextractf32x4 $3, %zmm1, %xmm5
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm4, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm2, %xmm5
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm4
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm2[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm7 = xmm5[1,0]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm7
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm2, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm4, %xmm2
; AVX512BW-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm5 = xmm4[1,1,3,3]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm1, %xmm6
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm7 = xmm6[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm5, %xmm7
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm4, %xmm6
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm7 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm6[1,0]
; AVX512BW-NEXT: vucomiss %xmm7, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm5, %xmm0
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm4 = xmm4[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm5 = xmm6[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm0, %xmm0
; AVX512BW-NEXT: vinserti128 $1, %xmm2, %ymm0, %ymm2
; AVX512BW-NEXT: vextractf32x4 $1, %zmm3, %xmm0
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm4 = xmm0[1,1,3,3]
; AVX512BW-NEXT: vextractf32x4 $1, %zmm1, %xmm5
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm6 = xmm5[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm4, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm0, %xmm5
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm4
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm0[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm7 = xmm5[1,0]
; AVX512BW-NEXT: vucomiss %xmm6, %xmm7
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm5 = xmm5[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm0, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm4, %xmm0
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm4 = xmm3[1,1,3,3]
; AVX512BW-NEXT: vmovshdup {{.*#+}} xmm5 = xmm1[1,1,3,3]
; AVX512BW-NEXT: vucomiss %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vucomiss %xmm3, %xmm1
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmoval %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm4
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm3[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm6 = xmm1[1,0]
; AVX512BW-NEXT: vucomiss %xmm5, %xmm6
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmoval %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm4, %xmm4
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm3 = xmm3[3,1,2,3]
; AVX512BW-NEXT: vpermilps {{.*#+}} xmm1 = xmm1[3,1,2,3]
; AVX512BW-NEXT: vucomiss %xmm3, %xmm1
; AVX512BW-NEXT: cmoval %ecx, %eax
; AVX512BW-NEXT: vpinsrd $3, %eax, %xmm4, %xmm1
; AVX512BW-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: retq
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
%1 = fcmp ogt <32 x float> %a0, %a1
ret <32 x i1> %1
}
define <16 x i1> @test_cmp_v16i64(<16 x i64> %a0, <16 x i64> %a1) nounwind {
; SSE2-LABEL: test_cmp_v16i64:
; SSE2: # BB#0:
; SSE2-NEXT: movdqa {{.*#+}} xmm8 = [2147483648,0,2147483648,0]
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm9
; SSE2-NEXT: pxor %xmm8, %xmm9
; SSE2-NEXT: movdqa %xmm7, %xmm10
; SSE2-NEXT: pcmpgtd %xmm9, %xmm10
; SSE2-NEXT: pshufd {{.*#+}} xmm11 = xmm10[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm7, %xmm9
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm9[1,1,3,3]
; SSE2-NEXT: pand %xmm11, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm10[1,1,3,3]
; SSE2-NEXT: por %xmm7, %xmm9
; SSE2-NEXT: pxor %xmm8, %xmm6
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pxor %xmm8, %xmm7
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: movdqa %xmm6, %xmm10
; SSE2-NEXT: pcmpgtd %xmm7, %xmm10
; SSE2-NEXT: pshufd {{.*#+}} xmm11 = xmm10[0,0,2,2]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: pcmpeqd %xmm6, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm7[1,1,3,3]
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: pand %xmm11, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm10 = xmm10[1,1,3,3]
; SSE2-NEXT: por %xmm7, %xmm10
; SSE2-NEXT: packsswb %xmm9, %xmm10
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm5
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: movdqa %xmm5, %xmm6
; SSE2-NEXT: pcmpgtd %xmm7, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm6[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm5, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm7[1,1,3,3]
; SSE2-NEXT: pand %xmm9, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm6[1,1,3,3]
; SSE2-NEXT: por %xmm5, %xmm6
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pxor %xmm8, %xmm5
; SSE2-NEXT: movdqa %xmm4, %xmm7
; SSE2-NEXT: pcmpgtd %xmm5, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm7[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm4, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm5[1,1,3,3]
; SSE2-NEXT: pand %xmm9, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm7[1,1,3,3]
; SSE2-NEXT: por %xmm5, %xmm4
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: packsswb %xmm6, %xmm4
; SSE2-NEXT: packsswb %xmm10, %xmm4
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pxor %xmm8, %xmm5
; SSE2-NEXT: movdqa %xmm3, %xmm6
; SSE2-NEXT: pcmpgtd %xmm5, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm6[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm3, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm5[1,1,3,3]
; SSE2-NEXT: pand %xmm7, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm6[1,1,3,3]
; SSE2-NEXT: por %xmm3, %xmm5
; SSE2-NEXT: pxor %xmm8, %xmm2
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm2, %xmm6
; SSE2-NEXT: pcmpgtd %xmm3, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm6[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm2, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm7, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm6[1,1,3,3]
; SSE2-NEXT: por %xmm3, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: packsswb %xmm5, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm1, %xmm5
; SSE2-NEXT: pcmpgtd %xmm3, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm1, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm5[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: pxor {{[0-9]+}}(%rsp), %xmm8
; SSE2-NEXT: movdqa %xmm0, %xmm1
; SSE2-NEXT: pcmpgtd %xmm8, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm1[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm0, %xmm8
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm8[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
; SSE2-NEXT: por %xmm6, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE2-NEXT: packsswb %xmm3, %xmm0
; SSE2-NEXT: packsswb %xmm2, %xmm0
; SSE2-NEXT: packsswb %xmm4, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v16i64:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm7, %xmm6
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm4
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm5, %xmm4
; SSE42-NEXT: packsswb %xmm6, %xmm4
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm3, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm1
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; SSE42-NEXT: packsswb %xmm1, %xmm0
; SSE42-NEXT: packsswb %xmm2, %xmm0
; SSE42-NEXT: packsswb %xmm4, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v16i64:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm9
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpcmpgtq %xmm8, %xmm9, %xmm8
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vpcmpgtq %xmm7, %xmm3, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm8, %xmm3, %xmm8
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm7
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm7, %xmm3, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm6, %xmm2, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpacksswb %xmm8, %xmm2, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm6
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm6, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm5, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm5, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm4, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v16i64:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtq %ymm7, %ymm3, %ymm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq %ymm6, %ymm2, %ymm2
; AVX2-NEXT: vpacksswb %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vpcmpgtq %ymm5, %ymm1, %ymm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq %ymm4, %ymm0, %ymm0
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v16i64:
; AVX512F: # BB#0:
; AVX512F-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rcx
; AVX512F-NEXT: vextracti32x4 $3, %zmm0, %xmm5
; AVX512F-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512F-NEXT: xorl %eax, %eax
; AVX512F-NEXT: cmpq %rcx, %rdx
; AVX512F-NEXT: movq $-1, %rcx
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512F-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512F-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512F-NEXT: vextracti32x4 $2, %zmm0, %xmm6
; AVX512F-NEXT: vpextrq $1, %xmm6, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm7
; AVX512F-NEXT: vmovq %xmm5, %rdx
; AVX512F-NEXT: vmovq %xmm6, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm7[0]
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512F-NEXT: vextracti32x4 $1, %zmm2, %xmm5
; AVX512F-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512F-NEXT: vextracti32x4 $1, %zmm0, %xmm6
; AVX512F-NEXT: vpextrq $1, %xmm6, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm7
; AVX512F-NEXT: vmovq %xmm5, %rdx
; AVX512F-NEXT: vmovq %xmm6, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm7[0]
; AVX512F-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512F-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vmovq %xmm2, %rdx
; AVX512F-NEXT: vmovq %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm6[0]
; AVX512F-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm0
; AVX512F-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512F-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512F-NEXT: vextracti32x4 $3, %zmm1, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vmovq %xmm2, %rdx
; AVX512F-NEXT: vmovq %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm5[0]
; AVX512F-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512F-NEXT: vextracti32x4 $2, %zmm1, %xmm5
; AVX512F-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512F-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512F-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512F-NEXT: vextracti32x4 $1, %zmm1, %xmm5
; AVX512F-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm6
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512F-NEXT: vpextrq $1, %xmm3, %rdx
; AVX512F-NEXT: vpextrq $1, %xmm1, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vmovq %xmm3, %rdx
; AVX512F-NEXT: vmovq %xmm1, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: cmovgq %rcx, %rax
; AVX512F-NEXT: vmovq %rax, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm5[0]
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512F-NEXT: vpmovqd %zmm1, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16i64:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm2, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rcx
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm0, %xmm5
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512DQ-NEXT: xorl %eax, %eax
; AVX512DQ-NEXT: cmpq %rcx, %rdx
; AVX512DQ-NEXT: movq $-1, %rcx
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm2, %xmm5
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm0, %xmm6
; AVX512DQ-NEXT: vpextrq $1, %xmm6, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm7
; AVX512DQ-NEXT: vmovq %xmm5, %rdx
; AVX512DQ-NEXT: vmovq %xmm6, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm7[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm2, %xmm5
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm0, %xmm6
; AVX512DQ-NEXT: vpextrq $1, %xmm6, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm7
; AVX512DQ-NEXT: vmovq %xmm5, %rdx
; AVX512DQ-NEXT: vmovq %xmm6, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm7[0]
; AVX512DQ-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vmovq %xmm2, %rdx
; AVX512DQ-NEXT: vmovq %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm6[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm0
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm3, %xmm2
; AVX512DQ-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm1, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vmovq %xmm2, %rdx
; AVX512DQ-NEXT: vmovq %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm5[0]
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm3, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm1, %xmm5
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm3, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm1, %xmm5
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm6
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512DQ-NEXT: vpextrq $1, %xmm3, %rdx
; AVX512DQ-NEXT: vpextrq $1, %xmm1, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vmovq %xmm3, %rdx
; AVX512DQ-NEXT: vmovq %xmm1, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: cmovgq %rcx, %rax
; AVX512DQ-NEXT: vmovq %rax, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm5[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512DQ-NEXT: vpmovqd %zmm1, %ymm1
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm1, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16i64:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rcx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm0, %xmm5
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: cmpq %rcx, %rdx
; AVX512BW-NEXT: movq $-1, %rcx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512BW-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm0, %xmm6
; AVX512BW-NEXT: vpextrq $1, %xmm6, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm7
; AVX512BW-NEXT: vmovq %xmm5, %rdx
; AVX512BW-NEXT: vmovq %xmm6, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm7[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512BW-NEXT: vextracti32x4 $1, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm0, %xmm6
; AVX512BW-NEXT: vpextrq $1, %xmm6, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm7
; AVX512BW-NEXT: vmovq %xmm5, %rdx
; AVX512BW-NEXT: vmovq %xmm6, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm7[0]
; AVX512BW-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vmovq %xmm2, %rdx
; AVX512BW-NEXT: vmovq %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm6[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm0
; AVX512BW-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm1, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vmovq %xmm2, %rdx
; AVX512BW-NEXT: vmovq %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm5[0]
; AVX512BW-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm1, %xmm5
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512BW-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm1, %xmm5
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm6
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; AVX512BW-NEXT: vpextrq $1, %xmm3, %rdx
; AVX512BW-NEXT: vpextrq $1, %xmm1, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vmovq %xmm3, %rdx
; AVX512BW-NEXT: vmovq %xmm1, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: cmovgq %rcx, %rax
; AVX512BW-NEXT: vmovq %rax, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm5[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512BW-NEXT: vpmovqd %zmm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovdb %zmm0, %xmm0
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512BW-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512BW-NEXT: retq
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
%1 = icmp sgt <16 x i64> %a0, %a1
ret <16 x i1> %1
}
define <32 x i1> @test_cmp_v32i32(<32 x i32> %a0, <32 x i32> %a1) nounwind {
; SSE2-LABEL: test_cmp_v32i32:
; SSE2: # BB#0:
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pshuflw {{.*#+}} xmm3 = xmm3[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm3 = xmm3[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[0,2,2,3]
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm2[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; SSE2-NEXT: psllw $15, %xmm2
; SSE2-NEXT: psraw $15, %xmm2
; SSE2-NEXT: movdqa {{.*#+}} xmm3 = [255,255,255,255,255,255,255,255]
; SSE2-NEXT: pand %xmm3, %xmm2
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm1[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: psllw $15, %xmm0
; SSE2-NEXT: psraw $15, %xmm0
; SSE2-NEXT: pand %xmm3, %xmm0
; SSE2-NEXT: packuswb %xmm2, %xmm0
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm7[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm6[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
; SSE2-NEXT: psllw $15, %xmm2
; SSE2-NEXT: psraw $15, %xmm2
; SSE2-NEXT: pand %xmm3, %xmm2
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm5[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pshuflw {{.*#+}} xmm4 = xmm4[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm4 = xmm4[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm4[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm1[0]
; SSE2-NEXT: psllw $15, %xmm4
; SSE2-NEXT: psraw $15, %xmm4
; SSE2-NEXT: pand %xmm3, %xmm4
; SSE2-NEXT: packuswb %xmm2, %xmm4
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, nhaehnle, jyknight Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 282600
2016-09-28 23:50:43 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after upstream changes. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 284151
2016-10-14 03:20:16 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing overly aggressive load-store forwarding optimization. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289221
2016-12-10 00:15:12 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i32:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm1
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movdqa {{.*#+}} xmm8 = [0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pshufb %xmm8, %xmm1
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pshufb %xmm8, %xmm0
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE42-NEXT: psllw $15, %xmm0
; SSE42-NEXT: psraw $15, %xmm0
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: pshufb %xmm8, %xmm3
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: pshufb %xmm8, %xmm2
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; SSE42-NEXT: psllw $15, %xmm2
; SSE42-NEXT: psraw $15, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pshufb %xmm8, %xmm5
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: pshufb %xmm8, %xmm4
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm5[0]
; SSE42-NEXT: psllw $15, %xmm4
; SSE42-NEXT: psraw $15, %xmm4
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: pshufb %xmm8, %xmm7
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: pshufb %xmm8, %xmm6
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm6 = xmm6[0],xmm7[0]
; SSE42-NEXT: psllw $15, %xmm6
; SSE42-NEXT: psraw $15, %xmm6
; SSE42-NEXT: pextrb $14, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $0, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i32:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm9
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpcmpgtd %xmm8, %xmm9, %xmm8
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vpcmpgtd %xmm7, %xmm3, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm8, %xmm3, %xmm8
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm7
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm7, %xmm3, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm6, %xmm2, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpacksswb %xmm8, %xmm2, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm6
; AVX1-NEXT: vpcmpgtd %xmm3, %xmm6, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm5, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
; AVX1-NEXT: vpcmpgtd %xmm3, %xmm5, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm4, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v32i32:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtd %ymm7, %ymm3, %ymm3
; AVX2-NEXT: vpcmpgtd %ymm6, %ymm2, %ymm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vpcmpgtd %ymm5, %ymm1, %ymm1
; AVX2-NEXT: vpcmpgtd %ymm4, %ymm0, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v32i32:
; AVX512F: # BB#0:
; AVX512F-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512F-NEXT: vpextrd $1, %xmm4, %ecx
; AVX512F-NEXT: vextracti32x4 $3, %zmm0, %xmm5
; AVX512F-NEXT: vpextrd $1, %xmm5, %edx
; AVX512F-NEXT: xorl %eax, %eax
; AVX512F-NEXT: cmpl %ecx, %edx
; AVX512F-NEXT: movl $-1, %ecx
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm4, %esi
; AVX512F-NEXT: vmovd %xmm5, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm6
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $2, %xmm4, %edx
; AVX512F-NEXT: vpextrd $2, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $3, %xmm4, %edx
; AVX512F-NEXT: vpextrd $3, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512F-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512F-NEXT: vpextrd $1, %xmm5, %edx
; AVX512F-NEXT: vextracti32x4 $2, %zmm0, %xmm6
; AVX512F-NEXT: vpextrd $1, %xmm6, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm5, %esi
; AVX512F-NEXT: vmovd %xmm6, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm7
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm7, %xmm7
; AVX512F-NEXT: vpextrd $2, %xmm5, %edx
; AVX512F-NEXT: vpextrd $2, %xmm6, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm7, %xmm7
; AVX512F-NEXT: vpextrd $3, %xmm5, %edx
; AVX512F-NEXT: vpextrd $3, %xmm6, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm7, %xmm5
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512F-NEXT: vextracti32x4 $1, %zmm2, %xmm5
; AVX512F-NEXT: vpextrd $1, %xmm5, %edx
; AVX512F-NEXT: vextracti32x4 $1, %zmm0, %xmm6
; AVX512F-NEXT: vpextrd $1, %xmm6, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm5, %esi
; AVX512F-NEXT: vmovd %xmm6, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm7
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm7, %xmm7
; AVX512F-NEXT: vpextrd $2, %xmm5, %edx
; AVX512F-NEXT: vpextrd $2, %xmm6, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm7, %xmm7
; AVX512F-NEXT: vpextrd $3, %xmm5, %edx
; AVX512F-NEXT: vpextrd $3, %xmm6, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm7, %xmm5
; AVX512F-NEXT: vpextrd $1, %xmm2, %edx
; AVX512F-NEXT: vpextrd $1, %xmm0, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm2, %esi
; AVX512F-NEXT: vmovd %xmm0, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm6
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $2, %xmm2, %edx
; AVX512F-NEXT: vpextrd $2, %xmm0, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $3, %xmm2, %edx
; AVX512F-NEXT: vpextrd $3, %xmm0, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm6, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512F-NEXT: vpextrd $1, %xmm2, %edx
; AVX512F-NEXT: vextracti32x4 $3, %zmm1, %xmm4
; AVX512F-NEXT: vpextrd $1, %xmm4, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm2, %esi
; AVX512F-NEXT: vmovd %xmm4, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm5
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpextrd $2, %xmm2, %edx
; AVX512F-NEXT: vpextrd $2, %xmm4, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpextrd $3, %xmm2, %edx
; AVX512F-NEXT: vpextrd $3, %xmm4, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm5, %xmm2
; AVX512F-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512F-NEXT: vpextrd $1, %xmm4, %edx
; AVX512F-NEXT: vextracti32x4 $2, %zmm1, %xmm5
; AVX512F-NEXT: vpextrd $1, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm4, %esi
; AVX512F-NEXT: vmovd %xmm5, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm6
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $2, %xmm4, %edx
; AVX512F-NEXT: vpextrd $2, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $3, %xmm4, %edx
; AVX512F-NEXT: vpextrd $3, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512F-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512F-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512F-NEXT: vpextrd $1, %xmm4, %edx
; AVX512F-NEXT: vextracti32x4 $1, %zmm1, %xmm5
; AVX512F-NEXT: vpextrd $1, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm4, %esi
; AVX512F-NEXT: vmovd %xmm5, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm6
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $2, %xmm4, %edx
; AVX512F-NEXT: vpextrd $2, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512F-NEXT: vpextrd $3, %xmm4, %edx
; AVX512F-NEXT: vpextrd $3, %xmm5, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512F-NEXT: vpextrd $1, %xmm3, %edx
; AVX512F-NEXT: vpextrd $1, %xmm1, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vmovd %xmm3, %esi
; AVX512F-NEXT: vmovd %xmm1, %edi
; AVX512F-NEXT: cmpl %esi, %edi
; AVX512F-NEXT: movl $0, %esi
; AVX512F-NEXT: cmovgl %ecx, %esi
; AVX512F-NEXT: vmovd %esi, %xmm5
; AVX512F-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpextrd $2, %xmm3, %edx
; AVX512F-NEXT: vpextrd $2, %xmm1, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgl %ecx, %edx
; AVX512F-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512F-NEXT: vpextrd $3, %xmm3, %edx
; AVX512F-NEXT: vpextrd $3, %xmm1, %esi
; AVX512F-NEXT: cmpl %edx, %esi
; AVX512F-NEXT: cmovgl %ecx, %eax
; AVX512F-NEXT: vpinsrd $3, %eax, %xmm5, %xmm1
; AVX512F-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v32i32:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512DQ-NEXT: vpextrd $1, %xmm4, %ecx
; AVX512DQ-NEXT: vextracti32x4 $3, %zmm0, %xmm5
; AVX512DQ-NEXT: vpextrd $1, %xmm5, %edx
; AVX512DQ-NEXT: xorl %eax, %eax
; AVX512DQ-NEXT: cmpl %ecx, %edx
; AVX512DQ-NEXT: movl $-1, %ecx
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm4, %esi
; AVX512DQ-NEXT: vmovd %xmm5, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm6
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $2, %xmm4, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $3, %xmm4, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512DQ-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512DQ-NEXT: vpextrd $1, %xmm5, %edx
; AVX512DQ-NEXT: vextracti32x4 $2, %zmm0, %xmm6
; AVX512DQ-NEXT: vpextrd $1, %xmm6, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm5, %esi
; AVX512DQ-NEXT: vmovd %xmm6, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm7
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm7, %xmm7
; AVX512DQ-NEXT: vpextrd $2, %xmm5, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm6, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm7, %xmm7
; AVX512DQ-NEXT: vpextrd $3, %xmm5, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm6, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm7, %xmm5
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512DQ-NEXT: vextracti32x4 $1, %zmm2, %xmm5
; AVX512DQ-NEXT: vpextrd $1, %xmm5, %edx
; AVX512DQ-NEXT: vextracti32x4 $1, %zmm0, %xmm6
; AVX512DQ-NEXT: vpextrd $1, %xmm6, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm5, %esi
; AVX512DQ-NEXT: vmovd %xmm6, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm7
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm7, %xmm7
; AVX512DQ-NEXT: vpextrd $2, %xmm5, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm6, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm7, %xmm7
; AVX512DQ-NEXT: vpextrd $3, %xmm5, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm6, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm7, %xmm5
; AVX512DQ-NEXT: vpextrd $1, %xmm2, %edx
; AVX512DQ-NEXT: vpextrd $1, %xmm0, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm2, %esi
; AVX512DQ-NEXT: vmovd %xmm0, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm6
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $2, %xmm2, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm0, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $3, %xmm2, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm0, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm6, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm4, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512DQ-NEXT: vpextrd $1, %xmm2, %edx
; AVX512DQ-NEXT: vextracti32x4 $3, %zmm1, %xmm4
; AVX512DQ-NEXT: vpextrd $1, %xmm4, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm2, %esi
; AVX512DQ-NEXT: vmovd %xmm4, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm5
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpextrd $2, %xmm2, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm4, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpextrd $3, %xmm2, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm4, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm5, %xmm2
; AVX512DQ-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512DQ-NEXT: vpextrd $1, %xmm4, %edx
; AVX512DQ-NEXT: vextracti32x4 $2, %zmm1, %xmm5
; AVX512DQ-NEXT: vpextrd $1, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm4, %esi
; AVX512DQ-NEXT: vmovd %xmm5, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm6
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $2, %xmm4, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $3, %xmm4, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512DQ-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512DQ-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512DQ-NEXT: vpextrd $1, %xmm4, %edx
; AVX512DQ-NEXT: vextracti32x4 $1, %zmm1, %xmm5
; AVX512DQ-NEXT: vpextrd $1, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm4, %esi
; AVX512DQ-NEXT: vmovd %xmm5, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm6
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $2, %xmm4, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512DQ-NEXT: vpextrd $3, %xmm4, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm5, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512DQ-NEXT: vpextrd $1, %xmm3, %edx
; AVX512DQ-NEXT: vpextrd $1, %xmm1, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vmovd %xmm3, %esi
; AVX512DQ-NEXT: vmovd %xmm1, %edi
; AVX512DQ-NEXT: cmpl %esi, %edi
; AVX512DQ-NEXT: movl $0, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %esi
; AVX512DQ-NEXT: vmovd %esi, %xmm5
; AVX512DQ-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpextrd $2, %xmm3, %edx
; AVX512DQ-NEXT: vpextrd $2, %xmm1, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgl %ecx, %edx
; AVX512DQ-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512DQ-NEXT: vpextrd $3, %xmm3, %edx
; AVX512DQ-NEXT: vpextrd $3, %xmm1, %esi
; AVX512DQ-NEXT: cmpl %edx, %esi
; AVX512DQ-NEXT: cmovgl %ecx, %eax
; AVX512DQ-NEXT: vpinsrd $3, %eax, %xmm5, %xmm1
; AVX512DQ-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm2, %zmm1, %zmm1
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v32i32:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vpextrd $1, %xmm4, %ecx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm0, %xmm5
; AVX512BW-NEXT: vpextrd $1, %xmm5, %edx
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: cmpl %ecx, %edx
; AVX512BW-NEXT: movl $-1, %ecx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm4, %esi
; AVX512BW-NEXT: vmovd %xmm5, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $2, %xmm4, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $3, %xmm4, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512BW-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrd $1, %xmm5, %edx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm0, %xmm6
; AVX512BW-NEXT: vpextrd $1, %xmm6, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm5, %esi
; AVX512BW-NEXT: vmovd %xmm6, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm7
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrd $2, %xmm5, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm6, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrd $3, %xmm5, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm6, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm7, %xmm5
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512BW-NEXT: vextracti32x4 $1, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrd $1, %xmm5, %edx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm0, %xmm6
; AVX512BW-NEXT: vpextrd $1, %xmm6, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm5, %esi
; AVX512BW-NEXT: vmovd %xmm6, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm7
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrd $2, %xmm5, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm6, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrd $3, %xmm5, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm6, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm7, %xmm5
; AVX512BW-NEXT: vpextrd $1, %xmm2, %edx
; AVX512BW-NEXT: vpextrd $1, %xmm0, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm2, %esi
; AVX512BW-NEXT: vmovd %xmm0, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $2, %xmm2, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm0, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $3, %xmm2, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm0, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm6, %xmm0
; AVX512BW-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm0
; AVX512BW-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vpextrd $1, %xmm2, %edx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm1, %xmm4
; AVX512BW-NEXT: vpextrd $1, %xmm4, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm2, %esi
; AVX512BW-NEXT: vmovd %xmm4, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrd $2, %xmm2, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm4, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrd $3, %xmm2, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm4, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm5, %xmm2
; AVX512BW-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrd $1, %xmm4, %edx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm1, %xmm5
; AVX512BW-NEXT: vpextrd $1, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm4, %esi
; AVX512BW-NEXT: vmovd %xmm5, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $2, %xmm4, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $3, %xmm4, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512BW-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512BW-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrd $1, %xmm4, %edx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm1, %xmm5
; AVX512BW-NEXT: vpextrd $1, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm4, %esi
; AVX512BW-NEXT: vmovd %xmm5, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $2, %xmm4, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrd $3, %xmm4, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm5, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $3, %edx, %xmm6, %xmm4
; AVX512BW-NEXT: vpextrd $1, %xmm3, %edx
; AVX512BW-NEXT: vpextrd $1, %xmm1, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vmovd %xmm3, %esi
; AVX512BW-NEXT: vmovd %xmm1, %edi
; AVX512BW-NEXT: cmpl %esi, %edi
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgl %ecx, %esi
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrd $1, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrd $2, %xmm3, %edx
; AVX512BW-NEXT: vpextrd $2, %xmm1, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgl %ecx, %edx
; AVX512BW-NEXT: vpinsrd $2, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrd $3, %xmm3, %edx
; AVX512BW-NEXT: vpextrd $3, %xmm1, %esi
; AVX512BW-NEXT: cmpl %edx, %esi
; AVX512BW-NEXT: cmovgl %ecx, %eax
; AVX512BW-NEXT: vpinsrd $3, %eax, %xmm5, %xmm1
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512BW-NEXT: vpmovdw %zmm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: retq
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
%1 = icmp sgt <32 x i32> %a0, %a1
ret <32 x i1> %1
}
define <64 x i1> @test_cmp_v64i16(<64 x i16> %a0, <64 x i16> %a1) nounwind {
; SSE2-LABEL: test_cmp_v64i16:
; SSE2: # BB#0:
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: movdqa {{.*#+}} xmm8 = [255,255,255,255,255,255,255,255]
; SSE2-NEXT: pand %xmm8, %xmm1
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pand %xmm8, %xmm0
; SSE2-NEXT: packuswb %xmm1, %xmm0
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pand %xmm8, %xmm3
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pand %xmm8, %xmm2
; SSE2-NEXT: packuswb %xmm3, %xmm2
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pand %xmm8, %xmm5
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pand %xmm8, %xmm4
; SSE2-NEXT: packuswb %xmm5, %xmm4
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pand %xmm8, %xmm7
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: pand %xmm8, %xmm6
; SSE2-NEXT: packuswb %xmm7, %xmm6
; SSE2-NEXT: movdqa %xmm6, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 4(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v64i16:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm0
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm2
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm3
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm4
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm5
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm6
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: pextrb $14, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm7, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm6, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $0, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm5, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm4, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $0, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm3, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm2, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $0, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm1, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm0, %eax
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v64i16:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm9
; AVX1-NEXT: vpcmpgtw %xmm8, %xmm9, %xmm8
; AVX1-NEXT: vpcmpgtw %xmm4, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm8, %xmm0, %xmm8
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm0
; AVX1-NEXT: vpcmpgtw %xmm4, %xmm0, %xmm0
; AVX1-NEXT: vpcmpgtw %xmm5, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm0, %xmm1, %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm0
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm4
; AVX1-NEXT: vpcmpgtw %xmm0, %xmm4, %xmm0
; AVX1-NEXT: vpcmpgtw %xmm6, %xmm2, %xmm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm0, %xmm2, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm0
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm4
; AVX1-NEXT: vpcmpgtw %xmm0, %xmm4, %xmm0
; AVX1-NEXT: vpcmpgtw %xmm7, %xmm3, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm0, %xmm3, %xmm3
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX1-NEXT: vpextrb $15, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $14, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $13, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $12, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $11, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $10, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $9, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $8, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $7, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $6, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $5, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $4, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $3, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $2, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $1, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $0, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $15, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $14, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $13, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $12, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $11, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $10, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $9, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $8, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $7, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $6, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $5, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $4, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $3, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $2, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $1, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $0, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: movq %rdi, %rax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v64i16:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtw %ymm4, %ymm0, %ymm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm4
; AVX2-NEXT: vpacksswb %xmm4, %xmm0, %xmm0
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vpcmpgtw %ymm5, %ymm1, %ymm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm1, %xmm4
; AVX2-NEXT: vpacksswb %xmm4, %xmm1, %xmm1
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vpcmpgtw %ymm6, %ymm2, %ymm2
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm2, %xmm4
; AVX2-NEXT: vpacksswb %xmm4, %xmm2, %xmm2
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vpcmpgtw %ymm7, %ymm3, %ymm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm3, %xmm4
; AVX2-NEXT: vpacksswb %xmm4, %xmm3, %xmm3
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; AVX2-NEXT: vpextrb $15, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $15, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $15, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $14, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $13, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $12, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $11, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $10, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $9, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $8, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $7, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $6, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $5, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $4, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $3, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $2, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $0, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $15, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $14, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $13, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $12, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $11, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $10, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $9, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $8, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $7, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $6, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $5, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $4, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $3, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $2, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $1, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $0, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: movq %rdi, %rax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v64i16:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtw %ymm7, %ymm3, %ymm3
; AVX512F-NEXT: vpmovsxwd %ymm3, %zmm3
; AVX512F-NEXT: vpslld $31, %zmm3, %zmm3
; AVX512F-NEXT: vptestmd %zmm3, %zmm3, %k0
; AVX512F-NEXT: kshiftlw $14, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: kshiftlw $15, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm3
; AVX512F-NEXT: vpinsrb $1, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $13, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $2, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $12, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $3, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $11, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $4, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $10, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $5, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $9, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $6, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $8, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $7, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $7, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $8, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $6, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $9, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $5, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $10, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $4, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $11, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $3, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $12, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $2, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $13, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftlw $1, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $14, %eax, %xmm3, %xmm3
; AVX512F-NEXT: kshiftrw $15, %k0, %k0
; AVX512F-NEXT: kmovw %k0, %eax
; AVX512F-NEXT: vpinsrb $15, %eax, %xmm3, %xmm3
; AVX512F-NEXT: vpcmpgtw %ymm6, %ymm2, %ymm2
; AVX512F-NEXT: vpmovsxwd %ymm2, %zmm2
; AVX512F-NEXT: vpslld $31, %zmm2, %zmm2
; AVX512F-NEXT: vptestmd %zmm2, %zmm2, %k0
; AVX512F-NEXT: kshiftlw $14, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: kshiftlw $15, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm2
; AVX512F-NEXT: vpinsrb $1, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $13, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $2, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $12, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $3, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $11, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $4, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $10, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $5, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $9, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $6, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $8, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $7, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $7, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $8, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $6, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $9, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $5, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $10, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $4, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $11, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $3, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $12, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $2, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $13, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftlw $1, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $14, %eax, %xmm2, %xmm2
; AVX512F-NEXT: kshiftrw $15, %k0, %k0
; AVX512F-NEXT: kmovw %k0, %eax
; AVX512F-NEXT: vpinsrb $15, %eax, %xmm2, %xmm2
; AVX512F-NEXT: vinserti128 $1, %xmm3, %ymm2, %ymm2
; AVX512F-NEXT: vpsllw $7, %ymm2, %ymm2
; AVX512F-NEXT: vmovdqa {{.*#+}} ymm3 = [128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128]
; AVX512F-NEXT: vpand %ymm3, %ymm2, %ymm2
; AVX512F-NEXT: vpxor %ymm6, %ymm6, %ymm6
; AVX512F-NEXT: vpcmpgtb %ymm2, %ymm6, %ymm2
; AVX512F-NEXT: vpcmpgtw %ymm5, %ymm1, %ymm1
; AVX512F-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512F-NEXT: vpslld $31, %zmm1, %zmm1
; AVX512F-NEXT: vptestmd %zmm1, %zmm1, %k0
; AVX512F-NEXT: kshiftlw $14, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: kshiftlw $15, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm1
; AVX512F-NEXT: vpinsrb $1, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $13, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $2, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $12, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $3, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $11, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $4, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $10, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $5, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $9, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $6, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $8, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $7, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $7, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $8, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $6, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $9, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $5, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $10, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $4, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $11, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $3, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $12, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $2, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $13, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftlw $1, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $14, %eax, %xmm1, %xmm1
; AVX512F-NEXT: kshiftrw $15, %k0, %k0
; AVX512F-NEXT: kmovw %k0, %eax
; AVX512F-NEXT: vpinsrb $15, %eax, %xmm1, %xmm1
; AVX512F-NEXT: vpcmpgtw %ymm4, %ymm0, %ymm0
; AVX512F-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512F-NEXT: vpslld $31, %zmm0, %zmm0
; AVX512F-NEXT: vptestmd %zmm0, %zmm0, %k0
; AVX512F-NEXT: kshiftlw $14, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: kshiftlw $15, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm0
; AVX512F-NEXT: vpinsrb $1, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $13, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $2, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $12, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $3, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $11, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $4, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $10, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $5, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $9, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $6, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $8, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $7, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $7, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $8, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $6, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $9, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $5, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $10, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $4, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $11, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $3, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $12, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $2, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $13, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftlw $1, %k0, %k1
; AVX512F-NEXT: kshiftrw $15, %k1, %k1
; AVX512F-NEXT: kmovw %k1, %eax
; AVX512F-NEXT: vpinsrb $14, %eax, %xmm0, %xmm0
; AVX512F-NEXT: kshiftrw $15, %k0, %k0
; AVX512F-NEXT: kmovw %k0, %eax
; AVX512F-NEXT: vpinsrb $15, %eax, %xmm0, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512F-NEXT: vpsllw $7, %ymm0, %ymm0
; AVX512F-NEXT: vpand %ymm3, %ymm0, %ymm0
; AVX512F-NEXT: vpcmpgtb %ymm0, %ymm6, %ymm0
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX512F-NEXT: vextracti128 $1, %ymm2, %xmm3
; AVX512F-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
; AVX512F-NEXT: # kill: %XMM2<def> %XMM2<kill> %YMM2<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v64i16:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtw %ymm7, %ymm3, %ymm3
; AVX512DQ-NEXT: vpmovsxwd %ymm3, %zmm3
; AVX512DQ-NEXT: vpslld $31, %zmm3, %zmm3
; AVX512DQ-NEXT: vptestmd %zmm3, %zmm3, %k0
; AVX512DQ-NEXT: kshiftlw $14, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: kshiftlw $15, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %ecx
; AVX512DQ-NEXT: vmovd %ecx, %xmm3
; AVX512DQ-NEXT: vpinsrb $1, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $13, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $2, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $12, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $3, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $11, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $4, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $10, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $5, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $9, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $6, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $8, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $7, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $7, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $8, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $6, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $9, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $5, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $10, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $4, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $11, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $3, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $12, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $2, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $13, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftlw $1, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $14, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: kshiftrw $15, %k0, %k0
; AVX512DQ-NEXT: kmovw %k0, %eax
; AVX512DQ-NEXT: vpinsrb $15, %eax, %xmm3, %xmm3
; AVX512DQ-NEXT: vpcmpgtw %ymm6, %ymm2, %ymm2
; AVX512DQ-NEXT: vpmovsxwd %ymm2, %zmm2
; AVX512DQ-NEXT: vpslld $31, %zmm2, %zmm2
; AVX512DQ-NEXT: vptestmd %zmm2, %zmm2, %k0
; AVX512DQ-NEXT: kshiftlw $14, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: kshiftlw $15, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %ecx
; AVX512DQ-NEXT: vmovd %ecx, %xmm2
; AVX512DQ-NEXT: vpinsrb $1, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $13, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $2, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $12, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $3, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $11, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $4, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $10, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $5, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $9, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $6, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $8, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $7, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $7, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $8, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $6, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $9, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $5, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $10, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $4, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $11, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $3, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $12, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $2, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $13, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftlw $1, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $14, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: kshiftrw $15, %k0, %k0
; AVX512DQ-NEXT: kmovw %k0, %eax
; AVX512DQ-NEXT: vpinsrb $15, %eax, %xmm2, %xmm2
; AVX512DQ-NEXT: vinserti128 $1, %xmm3, %ymm2, %ymm2
; AVX512DQ-NEXT: vpsllw $7, %ymm2, %ymm2
; AVX512DQ-NEXT: vmovdqa {{.*#+}} ymm3 = [128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128]
; AVX512DQ-NEXT: vpand %ymm3, %ymm2, %ymm2
; AVX512DQ-NEXT: vpxor %ymm6, %ymm6, %ymm6
; AVX512DQ-NEXT: vpcmpgtb %ymm2, %ymm6, %ymm2
; AVX512DQ-NEXT: vpcmpgtw %ymm5, %ymm1, %ymm1
; AVX512DQ-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512DQ-NEXT: vpslld $31, %zmm1, %zmm1
; AVX512DQ-NEXT: vptestmd %zmm1, %zmm1, %k0
; AVX512DQ-NEXT: kshiftlw $14, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: kshiftlw $15, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %ecx
; AVX512DQ-NEXT: vmovd %ecx, %xmm1
; AVX512DQ-NEXT: vpinsrb $1, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $13, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $2, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $12, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $3, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $11, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $4, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $10, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $5, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $9, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $6, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $8, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $7, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $7, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $8, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $6, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $9, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $5, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $10, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $4, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $11, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $3, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $12, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $2, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $13, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftlw $1, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $14, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: kshiftrw $15, %k0, %k0
; AVX512DQ-NEXT: kmovw %k0, %eax
; AVX512DQ-NEXT: vpinsrb $15, %eax, %xmm1, %xmm1
; AVX512DQ-NEXT: vpcmpgtw %ymm4, %ymm0, %ymm0
; AVX512DQ-NEXT: vpmovsxwd %ymm0, %zmm0
; AVX512DQ-NEXT: vpslld $31, %zmm0, %zmm0
; AVX512DQ-NEXT: vptestmd %zmm0, %zmm0, %k0
; AVX512DQ-NEXT: kshiftlw $14, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: kshiftlw $15, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %ecx
; AVX512DQ-NEXT: vmovd %ecx, %xmm0
; AVX512DQ-NEXT: vpinsrb $1, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $13, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $2, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $12, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $3, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $11, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $4, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $10, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $5, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $9, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $6, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $8, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $7, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $7, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $8, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $6, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $9, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $5, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $10, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $4, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $11, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $3, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $12, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $2, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $13, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftlw $1, %k0, %k1
; AVX512DQ-NEXT: kshiftrw $15, %k1, %k1
; AVX512DQ-NEXT: kmovw %k1, %eax
; AVX512DQ-NEXT: vpinsrb $14, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: kshiftrw $15, %k0, %k0
; AVX512DQ-NEXT: kmovw %k0, %eax
; AVX512DQ-NEXT: vpinsrb $15, %eax, %xmm0, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512DQ-NEXT: vpsllw $7, %ymm0, %ymm0
; AVX512DQ-NEXT: vpand %ymm3, %ymm0, %ymm0
; AVX512DQ-NEXT: vpcmpgtb %ymm0, %ymm6, %ymm0
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX512DQ-NEXT: vextracti128 $1, %ymm2, %xmm3
; AVX512DQ-NEXT: # kill: %XMM0<def> %XMM0<kill> %YMM0<kill>
; AVX512DQ-NEXT: # kill: %XMM2<def> %XMM2<kill> %YMM2<kill>
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v64i16:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vpextrw $1, %xmm4, %ecx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm0, %xmm5
; AVX512BW-NEXT: vpextrw $1, %xmm5, %edx
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: cmpw %cx, %dx
; AVX512BW-NEXT: movw $-1, %cx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm4, %esi
; AVX512BW-NEXT: vmovd %xmm5, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $2, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $3, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $4, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $5, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $6, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $7, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm6, %xmm4
; AVX512BW-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrw $1, %xmm5, %edx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm0, %xmm6
; AVX512BW-NEXT: vpextrw $1, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm5, %esi
; AVX512BW-NEXT: vmovd %xmm6, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm7
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $2, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $3, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $4, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $5, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $6, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $7, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm7, %xmm5
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm5, %ymm4
; AVX512BW-NEXT: vextracti32x4 $1, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrw $1, %xmm5, %edx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm0, %xmm6
; AVX512BW-NEXT: vpextrw $1, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm5, %esi
; AVX512BW-NEXT: vmovd %xmm6, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm7
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $2, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $3, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $4, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $5, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $6, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm7, %xmm7
; AVX512BW-NEXT: vpextrw $7, %xmm5, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm6, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm7, %xmm5
; AVX512BW-NEXT: vpextrw $1, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $1, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm2, %esi
; AVX512BW-NEXT: vmovd %xmm0, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $2, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $3, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $4, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $5, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $6, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $7, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm0, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm6, %xmm0
; AVX512BW-NEXT: vinserti128 $1, %xmm5, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vpextrw $1, %xmm2, %edx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm1, %xmm4
; AVX512BW-NEXT: vpextrw $1, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm2, %esi
; AVX512BW-NEXT: vmovd %xmm4, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $2, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $3, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $4, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $5, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $6, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $7, %xmm2, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm4, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm5, %xmm2
; AVX512BW-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrw $1, %xmm4, %edx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm1, %xmm5
; AVX512BW-NEXT: vpextrw $1, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm4, %esi
; AVX512BW-NEXT: vmovd %xmm5, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $2, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $3, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $4, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $5, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $6, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $7, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm6, %xmm4
; AVX512BW-NEXT: vinserti128 $1, %xmm2, %ymm4, %ymm2
; AVX512BW-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrw $1, %xmm4, %edx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm1, %xmm5
; AVX512BW-NEXT: vpextrw $1, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm4, %esi
; AVX512BW-NEXT: vmovd %xmm5, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm6
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $2, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $3, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $4, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $5, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $6, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm6, %xmm6
; AVX512BW-NEXT: vpextrw $7, %xmm4, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm5, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $7, %edx, %xmm6, %xmm4
; AVX512BW-NEXT: vpextrw $1, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $1, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vmovd %xmm3, %esi
; AVX512BW-NEXT: vmovd %xmm1, %edi
; AVX512BW-NEXT: cmpw %si, %di
; AVX512BW-NEXT: movl $0, %esi
; AVX512BW-NEXT: cmovgw %cx, %si
; AVX512BW-NEXT: vmovd %esi, %xmm5
; AVX512BW-NEXT: vpinsrw $1, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $2, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $2, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $2, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $3, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $3, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $3, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $4, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $4, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $4, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $5, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $5, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $5, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $6, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $6, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgw %cx, %dx
; AVX512BW-NEXT: vpinsrw $6, %edx, %xmm5, %xmm5
; AVX512BW-NEXT: vpextrw $7, %xmm3, %edx
; AVX512BW-NEXT: vpextrw $7, %xmm1, %esi
; AVX512BW-NEXT: cmpw %dx, %si
; AVX512BW-NEXT: cmovgw %cx, %ax
; AVX512BW-NEXT: vpinsrw $7, %eax, %xmm5, %xmm1
; AVX512BW-NEXT: vinserti128 $1, %xmm4, %ymm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm2, %zmm1, %zmm1
; AVX512BW-NEXT: vpmovwb %zmm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512BW-NEXT: retq
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
%1 = icmp sgt <64 x i16> %a0, %a1
ret <64 x i1> %1
}
define <128 x i1> @test_cmp_v128i8(<128 x i8> %a0, <128 x i8> %a1) nounwind {
; SSE2-LABEL: test_cmp_v128i8:
; SSE2: # BB#0:
; SSE2-NEXT: pushq %rax
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: movdqa %xmm7, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 14(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm6, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
; SSE2-NEXT: movdqa %xmm5, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
; SSE2-NEXT: movdqa %xmm3, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
; SSE2-NEXT: movdqa %xmm1, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 10(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 8(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 8(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 4(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 4(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 14(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 12(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 10(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 8(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 6(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 4(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: popq %rcx
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v128i8:
; SSE42: # BB#0:
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm1
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: pcmpgtb {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: pextrb $15, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $14, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $13, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $12, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $11, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $10, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $9, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $8, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $7, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $6, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $5, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $4, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $3, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $2, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $1, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $0, %xmm7, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 14(%rdi)
; SSE42-NEXT: pextrb $15, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $14, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $13, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $12, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $11, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $10, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $9, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $8, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $7, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $6, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $5, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $4, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $3, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $2, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $1, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $0, %xmm6, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 12(%rdi)
; SSE42-NEXT: pextrb $15, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $14, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $13, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $12, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $11, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $10, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $9, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $8, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $7, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $6, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $5, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $4, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $3, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $2, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $1, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $0, %xmm5, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 10(%rdi)
; SSE42-NEXT: pextrb $15, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $14, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $13, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $12, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $11, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $10, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $9, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $8, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $7, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $6, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $5, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $4, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $3, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $2, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $1, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $0, %xmm4, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 8(%rdi)
; SSE42-NEXT: pextrb $15, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $14, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $13, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $12, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $11, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $10, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $9, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $8, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $7, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $6, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $5, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $4, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $3, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $2, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $1, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $0, %xmm3, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 6(%rdi)
; SSE42-NEXT: pextrb $15, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $14, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $13, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $12, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $11, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $10, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $9, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $8, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $7, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $6, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $5, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $4, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $3, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $2, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $1, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $0, %xmm2, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 4(%rdi)
; SSE42-NEXT: pextrb $15, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $14, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $13, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $12, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $11, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $10, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $9, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $8, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $7, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $6, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $5, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $4, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $3, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $2, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $1, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $0, %xmm1, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: pextrb $15, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $14, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $13, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $12, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $11, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $10, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $9, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $8, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $7, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $6, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $5, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $4, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $3, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $2, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $1, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v128i8:
; AVX1: # BB#0:
; AVX1-NEXT: vpcmpgtb %xmm4, %xmm0, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpcmpgtb %xmm4, %xmm0, %xmm0
; AVX1-NEXT: vpcmpgtb %xmm5, %xmm1, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
; AVX1-NEXT: vpcmpgtb %xmm5, %xmm1, %xmm1
; AVX1-NEXT: vpcmpgtb %xmm6, %xmm2, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm6
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm2
; AVX1-NEXT: vpcmpgtb %xmm6, %xmm2, %xmm2
; AVX1-NEXT: vpcmpgtb %xmm7, %xmm3, %xmm6
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm7
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm3
; AVX1-NEXT: vpcmpgtb %xmm7, %xmm3, %xmm3
; AVX1-NEXT: vpextrb $15, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm3, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm6, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 12(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm2, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm5, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 8(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm1, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $14, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $13, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $12, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $11, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $10, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $9, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $8, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $7, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $6, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $5, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $4, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $3, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $2, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $0, %xmm4, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, 4(%rdi)
; AVX1-NEXT: vpextrb $15, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $14, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $13, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $12, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $11, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $10, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $9, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $8, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $7, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $6, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $5, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $4, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $3, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $2, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $1, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $0, %xmm0, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $15, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $14, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $13, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $12, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $11, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $10, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $9, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $8, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $7, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $6, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $5, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $4, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $3, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $2, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $1, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: vpextrb $0, %xmm8, %eax
; AVX1-NEXT: andb $1, %al
; AVX1-NEXT: movb %al, (%rdi)
; AVX1-NEXT: movq %rdi, %rax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v128i8:
; AVX2: # BB#0:
; AVX2-NEXT: vpcmpgtb %ymm4, %ymm0, %ymm0
; AVX2-NEXT: vpcmpgtb %ymm5, %ymm1, %ymm1
; AVX2-NEXT: vpcmpgtb %ymm6, %ymm2, %ymm2
; AVX2-NEXT: vpcmpgtb %ymm7, %ymm3, %ymm3
; AVX2-NEXT: vextracti128 $1, %ymm3, %xmm4
; AVX2-NEXT: vpextrb $15, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm4, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $15, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 12(%rdi)
; AVX2-NEXT: vextracti128 $1, %ymm2, %xmm3
; AVX2-NEXT: vpextrb $15, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm3, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $15, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 8(%rdi)
; AVX2-NEXT: vextracti128 $1, %ymm1, %xmm2
; AVX2-NEXT: vpextrb $15, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm2, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $15, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $14, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $13, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $12, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $11, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $10, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $9, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $8, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $7, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $6, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $5, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $4, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $3, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $2, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vpextrb $0, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, 4(%rdi)
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpextrb $15, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $14, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $13, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $12, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $11, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $10, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $9, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $8, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $7, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $6, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $5, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $4, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $3, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $2, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $0, %xmm1, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $15, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $14, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $13, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $12, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $11, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $10, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $9, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $8, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $7, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $6, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $5, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $4, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $3, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $2, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $1, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: vpextrb $0, %xmm0, %eax
; AVX2-NEXT: andb $1, %al
; AVX2-NEXT: movb %al, (%rdi)
; AVX2-NEXT: movq %rdi, %rax
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v128i8:
; AVX512F: # BB#0:
; AVX512F-NEXT: vpcmpgtb %ymm4, %ymm0, %ymm0
; AVX512F-NEXT: vpcmpgtb %ymm5, %ymm1, %ymm1
; AVX512F-NEXT: vpcmpgtb %ymm6, %ymm2, %ymm2
; AVX512F-NEXT: vpcmpgtb %ymm7, %ymm3, %ymm3
; AVX512F-NEXT: vextracti128 $1, %ymm3, %xmm4
; AVX512F-NEXT: vpmovsxbd %xmm4, %zmm4
; AVX512F-NEXT: vpslld $31, %zmm4, %zmm4
; AVX512F-NEXT: vptestmd %zmm4, %zmm4, %k0
; AVX512F-NEXT: kmovw %k0, 14(%rdi)
; AVX512F-NEXT: vpmovsxbd %xmm3, %zmm3
; AVX512F-NEXT: vpslld $31, %zmm3, %zmm3
; AVX512F-NEXT: vptestmd %zmm3, %zmm3, %k0
; AVX512F-NEXT: kmovw %k0, 12(%rdi)
; AVX512F-NEXT: vextracti128 $1, %ymm2, %xmm3
; AVX512F-NEXT: vpmovsxbd %xmm3, %zmm3
; AVX512F-NEXT: vpslld $31, %zmm3, %zmm3
; AVX512F-NEXT: vptestmd %zmm3, %zmm3, %k0
; AVX512F-NEXT: kmovw %k0, 10(%rdi)
; AVX512F-NEXT: vpmovsxbd %xmm2, %zmm2
; AVX512F-NEXT: vpslld $31, %zmm2, %zmm2
; AVX512F-NEXT: vptestmd %zmm2, %zmm2, %k0
; AVX512F-NEXT: kmovw %k0, 8(%rdi)
; AVX512F-NEXT: vextracti128 $1, %ymm1, %xmm2
; AVX512F-NEXT: vpmovsxbd %xmm2, %zmm2
; AVX512F-NEXT: vpslld $31, %zmm2, %zmm2
; AVX512F-NEXT: vptestmd %zmm2, %zmm2, %k0
; AVX512F-NEXT: kmovw %k0, 6(%rdi)
; AVX512F-NEXT: vpmovsxbd %xmm1, %zmm1
; AVX512F-NEXT: vpslld $31, %zmm1, %zmm1
; AVX512F-NEXT: vptestmd %zmm1, %zmm1, %k0
; AVX512F-NEXT: kmovw %k0, 4(%rdi)
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX512F-NEXT: vpmovsxbd %xmm1, %zmm1
; AVX512F-NEXT: vpslld $31, %zmm1, %zmm1
; AVX512F-NEXT: vptestmd %zmm1, %zmm1, %k0
; AVX512F-NEXT: kmovw %k0, 2(%rdi)
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm0
; AVX512F-NEXT: vpslld $31, %zmm0, %zmm0
; AVX512F-NEXT: vptestmd %zmm0, %zmm0, %k0
; AVX512F-NEXT: kmovw %k0, (%rdi)
; AVX512F-NEXT: movq %rdi, %rax
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512F-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v128i8:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vpcmpgtb %ymm4, %ymm0, %ymm0
; AVX512DQ-NEXT: vpcmpgtb %ymm5, %ymm1, %ymm1
; AVX512DQ-NEXT: vpcmpgtb %ymm6, %ymm2, %ymm2
; AVX512DQ-NEXT: vpcmpgtb %ymm7, %ymm3, %ymm3
; AVX512DQ-NEXT: vextracti128 $1, %ymm3, %xmm4
; AVX512DQ-NEXT: vpmovsxbd %xmm4, %zmm4
; AVX512DQ-NEXT: vpslld $31, %zmm4, %zmm4
; AVX512DQ-NEXT: vptestmd %zmm4, %zmm4, %k0
; AVX512DQ-NEXT: kmovw %k0, 14(%rdi)
; AVX512DQ-NEXT: vpmovsxbd %xmm3, %zmm3
; AVX512DQ-NEXT: vpslld $31, %zmm3, %zmm3
; AVX512DQ-NEXT: vptestmd %zmm3, %zmm3, %k0
; AVX512DQ-NEXT: kmovw %k0, 12(%rdi)
; AVX512DQ-NEXT: vextracti128 $1, %ymm2, %xmm3
; AVX512DQ-NEXT: vpmovsxbd %xmm3, %zmm3
; AVX512DQ-NEXT: vpslld $31, %zmm3, %zmm3
; AVX512DQ-NEXT: vptestmd %zmm3, %zmm3, %k0
; AVX512DQ-NEXT: kmovw %k0, 10(%rdi)
; AVX512DQ-NEXT: vpmovsxbd %xmm2, %zmm2
; AVX512DQ-NEXT: vpslld $31, %zmm2, %zmm2
; AVX512DQ-NEXT: vptestmd %zmm2, %zmm2, %k0
; AVX512DQ-NEXT: kmovw %k0, 8(%rdi)
; AVX512DQ-NEXT: vextracti128 $1, %ymm1, %xmm2
; AVX512DQ-NEXT: vpmovsxbd %xmm2, %zmm2
; AVX512DQ-NEXT: vpslld $31, %zmm2, %zmm2
; AVX512DQ-NEXT: vptestmd %zmm2, %zmm2, %k0
; AVX512DQ-NEXT: kmovw %k0, 6(%rdi)
; AVX512DQ-NEXT: vpmovsxbd %xmm1, %zmm1
; AVX512DQ-NEXT: vpslld $31, %zmm1, %zmm1
; AVX512DQ-NEXT: vptestmd %zmm1, %zmm1, %k0
; AVX512DQ-NEXT: kmovw %k0, 4(%rdi)
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX512DQ-NEXT: vpmovsxbd %xmm1, %zmm1
; AVX512DQ-NEXT: vpslld $31, %zmm1, %zmm1
; AVX512DQ-NEXT: vptestmd %zmm1, %zmm1, %k0
; AVX512DQ-NEXT: kmovw %k0, 2(%rdi)
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm0
; AVX512DQ-NEXT: vpslld $31, %zmm0, %zmm0
; AVX512DQ-NEXT: vptestmd %zmm0, %zmm0, %k0
; AVX512DQ-NEXT: kmovw %k0, (%rdi)
; AVX512DQ-NEXT: movq %rdi, %rax
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
; AVX512DQ-NEXT: vzeroupper
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v128i8:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vpcmpgtb %zmm3, %zmm1, %k0
; AVX512BW-NEXT: vpcmpgtb %zmm2, %zmm0, %k1
; AVX512BW-NEXT: vpmovm2b %k1, %zmm0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm1
; AVX512BW-NEXT: retq
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor vector splitting for AVX512F targets as well as missing uses of PACKSS/MOVMSK llvm-svn: 265248
2016-04-03 05:33:09 +08:00
%1 = icmp sgt <128 x i8> %a0, %a1
ret <128 x i1> %1
}
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
;
; 2048-bit vector comparisons
;
define <32 x i1> @test_cmp_v32f64(<32 x double> %a0, <32 x double> %a1) nounwind {
; SSE2-LABEL: test_cmp_v32f64:
; SSE2: # BB#0:
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm8
; SSE2-NEXT: cmpltpd %xmm7, %xmm8
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: cmpltpd %xmm6, %xmm7
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm7 = xmm7[0,2],xmm8[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: cmpltpd %xmm5, %xmm6
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd %xmm4, %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm5 = xmm5[0,2],xmm6[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pslld $31, %xmm7
; SSE2-NEXT: psrad $31, %xmm7
; SSE2-NEXT: pshuflw {{.*#+}} xmm4 = xmm7[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm4 = xmm4[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm4[0,2,2,3]
; SSE2-NEXT: pslld $31, %xmm5
; SSE2-NEXT: psrad $31, %xmm5
; SSE2-NEXT: pshuflw {{.*#+}} xmm4 = xmm5[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm4 = xmm4[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm4[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd %xmm3, %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: cmpltpd %xmm2, %xmm6
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm2
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm6 = xmm6[0,2],xmm5[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd %xmm1, %xmm5
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: cmpltpd %xmm0, %xmm1
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,2],xmm5[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: psllw $15, %xmm4
; SSE2-NEXT: psraw $15, %xmm4
; SSE2-NEXT: pslld $31, %xmm6
; SSE2-NEXT: psrad $31, %xmm6
; SSE2-NEXT: pshuflw {{.*#+}} xmm0 = xmm6[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm0[0,2,2,3]
; SSE2-NEXT: pslld $31, %xmm1
; SSE2-NEXT: psrad $31, %xmm1
; SSE2-NEXT: pshuflw {{.*#+}} xmm0 = xmm1[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm6[0]
; SSE2-NEXT: movdqa {{.*#+}} xmm1 = [255,255,255,255,255,255,255,255]
; SSE2-NEXT: pand %xmm1, %xmm4
; SSE2-NEXT: psllw $15, %xmm0
; SSE2-NEXT: psraw $15, %xmm0
; SSE2-NEXT: pand %xmm1, %xmm0
; SSE2-NEXT: packuswb %xmm4, %xmm0
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm5 = xmm5[0,2],xmm4[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm3
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm3 = xmm3[0,2],xmm4[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pslld $31, %xmm5
; SSE2-NEXT: psrad $31, %xmm5
; SSE2-NEXT: pshuflw {{.*#+}} xmm5 = xmm5[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm5 = xmm5[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm5[0,2,2,3]
; SSE2-NEXT: pslld $31, %xmm3
; SSE2-NEXT: psrad $31, %xmm3
; SSE2-NEXT: pshuflw {{.*#+}} xmm3 = xmm3[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm3 = xmm3[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm3 = xmm3[0],xmm5[0]
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm4
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm4 = xmm4[0,2],xmm5[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm2
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm2 = xmm2[0,2],xmm5[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pslld $31, %xmm4
; SSE2-NEXT: psrad $31, %xmm4
; SSE2-NEXT: pshuflw {{.*#+}} xmm4 = xmm4[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm4 = xmm4[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm4[0,2,2,3]
; SSE2-NEXT: pslld $31, %xmm2
; SSE2-NEXT: psrad $31, %xmm2
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm2[0,2,2,3,4,5,6,7]
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm4[0]
; SSE2-NEXT: psllw $15, %xmm3
; SSE2-NEXT: psraw $15, %xmm3
; SSE2-NEXT: pand %xmm1, %xmm3
; SSE2-NEXT: psllw $15, %xmm2
; SSE2-NEXT: psraw $15, %xmm2
; SSE2-NEXT: pand %xmm1, %xmm2
; SSE2-NEXT: packuswb %xmm3, %xmm2
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, nhaehnle, jyknight Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 282600
2016-09-28 23:50:43 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after upstream changes. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 284151
2016-10-14 03:20:16 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing overly aggressive load-store forwarding optimization. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289221
2016-12-10 00:15:12 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32f64:
; SSE42: # BB#0:
; SSE42-NEXT: pushq %rbp
; SSE42-NEXT: pushq %r15
; SSE42-NEXT: pushq %r14
; SSE42-NEXT: pushq %r13
; SSE42-NEXT: pushq %r12
; SSE42-NEXT: pushq %rbx
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm8
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltpd %xmm3, %xmm8
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: cmpltpd %xmm2, %xmm3
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: shufps {{.*#+}} xmm3 = xmm3[0,2],xmm8[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm2
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltpd %xmm1, %xmm2
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: cmpltpd %xmm0, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: pslld $31, %xmm3
; SSE42-NEXT: psrad $31, %xmm3
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,2],xmm2[0,2]
; SSE42-NEXT: movdqa {{.*#+}} xmm8 = [0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; SSE42-NEXT: pshufb %xmm8, %xmm3
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: pslld $31, %xmm1
; SSE42-NEXT: psrad $31, %xmm1
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pshufb %xmm8, %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm3[0]
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd %xmm7, %xmm0
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: cmpltpd %xmm6, %xmm7
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: shufps {{.*#+}} xmm7 = xmm7[0,2],xmm0[0,2]
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: cmpltpd %xmm5, %xmm6
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd %xmm4, %xmm0
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,2],xmm6[0,2]
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: pslld $31, %xmm7
; SSE42-NEXT: psrad $31, %xmm7
; SSE42-NEXT: pshufb %xmm8, %xmm7
; SSE42-NEXT: pslld $31, %xmm0
; SSE42-NEXT: psrad $31, %xmm0
; SSE42-NEXT: pshufb %xmm8, %xmm0
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm7[0]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: shufps {{.*#+}} xmm4 = xmm4[0,2],xmm5[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: shufps {{.*#+}} xmm2 = xmm2[0,2],xmm5[0,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pslld $31, %xmm4
; SSE42-NEXT: psrad $31, %xmm4
; SSE42-NEXT: pshufb %xmm8, %xmm4
; SSE42-NEXT: pslld $31, %xmm2
; SSE42-NEXT: psrad $31, %xmm2
; SSE42-NEXT: pshufb %xmm8, %xmm2
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm4[0]
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm4
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: shufps {{.*#+}} xmm5 = xmm5[0,2],xmm4[0,2]
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: shufps {{.*#+}} xmm3 = xmm3[0,2],xmm4[0,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: pslld $31, %xmm5
; SSE42-NEXT: psrad $31, %xmm5
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pshufb %xmm8, %xmm5
; SSE42-NEXT: pslld $31, %xmm3
; SSE42-NEXT: psrad $31, %xmm3
; SSE42-NEXT: pshufb %xmm8, %xmm3
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm3 = xmm3[0],xmm5[0]
; SSE42-NEXT: psllw $15, %xmm3
; SSE42-NEXT: psraw $15, %xmm3
; SSE42-NEXT: pextrb $14, %xmm3, %ecx
; SSE42-NEXT: pextrb $12, %xmm3, %edx
; SSE42-NEXT: pextrb $10, %xmm3, %r8d
; SSE42-NEXT: pextrb $8, %xmm3, %r10d
; SSE42-NEXT: pextrb $6, %xmm3, %r14d
; SSE42-NEXT: pextrb $4, %xmm3, %r12d
; SSE42-NEXT: pextrb $2, %xmm3, %ebx
; SSE42-NEXT: pextrb $0, %xmm3, %eax
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: psllw $15, %xmm2
; SSE42-NEXT: psraw $15, %xmm2
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: andb $1, %cl
; SSE42-NEXT: movb %cl, 2(%rdi)
; SSE42-NEXT: andb $1, %dl
; SSE42-NEXT: movb %dl, 2(%rdi)
; SSE42-NEXT: pextrb $14, %xmm2, %edx
; SSE42-NEXT: pextrb $12, %xmm2, %esi
; SSE42-NEXT: pextrb $10, %xmm2, %r9d
; SSE42-NEXT: pextrb $8, %xmm2, %r11d
; SSE42-NEXT: pextrb $6, %xmm2, %r15d
; SSE42-NEXT: pextrb $4, %xmm2, %r13d
; SSE42-NEXT: pextrb $2, %xmm2, %ebp
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
; SSE42-NEXT: psllw $15, %xmm0
; SSE42-NEXT: psraw $15, %xmm0
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %r8b
; SSE42-NEXT: movb %r8b, 2(%rdi)
; SSE42-NEXT: andb $1, %r10b
; SSE42-NEXT: movb %r10b, 2(%rdi)
; SSE42-NEXT: andb $1, %r14b
; SSE42-NEXT: movb %r14b, 2(%rdi)
; SSE42-NEXT: andb $1, %r12b
; SSE42-NEXT: movb %r12b, 2(%rdi)
; SSE42-NEXT: andb $1, %bl
; SSE42-NEXT: movb %bl, 2(%rdi)
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
; SSE42-NEXT: andb $1, %dl
; SSE42-NEXT: movb %dl, 2(%rdi)
; SSE42-NEXT: andb $1, %sil
; SSE42-NEXT: movb %sil, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm0, %esi
; SSE42-NEXT: pextrb $12, %xmm0, %edx
; SSE42-NEXT: pextrb $10, %xmm0, %r8d
; SSE42-NEXT: pextrb $8, %xmm0, %r10d
; SSE42-NEXT: pextrb $6, %xmm0, %r14d
; SSE42-NEXT: pextrb $4, %xmm0, %r12d
; SSE42-NEXT: pextrb $2, %xmm0, %ebx
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: psllw $15, %xmm1
; SSE42-NEXT: psraw $15, %xmm1
; SSE42-NEXT: andb $1, %r9b
; SSE42-NEXT: movb %r9b, 2(%rdi)
; SSE42-NEXT: andb $1, %r11b
; SSE42-NEXT: movb %r11b, 2(%rdi)
; SSE42-NEXT: andb $1, %r15b
; SSE42-NEXT: movb %r15b, 2(%rdi)
; SSE42-NEXT: andb $1, %r13b
; SSE42-NEXT: movb %r13b, 2(%rdi)
; SSE42-NEXT: andb $1, %bpl
; SSE42-NEXT: movb %bpl, 2(%rdi)
; SSE42-NEXT: andb $1, %cl
; SSE42-NEXT: movb %cl, 2(%rdi)
; SSE42-NEXT: andb $1, %sil
; SSE42-NEXT: movb %sil, (%rdi)
; SSE42-NEXT: andb $1, %dl
; SSE42-NEXT: movb %dl, (%rdi)
; SSE42-NEXT: pextrb $14, %xmm1, %r9d
; SSE42-NEXT: pextrb $12, %xmm1, %r11d
; SSE42-NEXT: pextrb $10, %xmm1, %r15d
; SSE42-NEXT: pextrb $8, %xmm1, %r13d
; SSE42-NEXT: pextrb $6, %xmm1, %ecx
; SSE42-NEXT: pextrb $4, %xmm1, %edx
; SSE42-NEXT: pextrb $2, %xmm1, %esi
; SSE42-NEXT: pextrb $0, %xmm1, %ebp
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %r8b
; SSE42-NEXT: movb %r8b, (%rdi)
; SSE42-NEXT: andb $1, %r10b
; SSE42-NEXT: movb %r10b, (%rdi)
; SSE42-NEXT: andb $1, %r14b
; SSE42-NEXT: movb %r14b, (%rdi)
; SSE42-NEXT: andb $1, %r12b
; SSE42-NEXT: movb %r12b, (%rdi)
; SSE42-NEXT: andb $1, %bl
; SSE42-NEXT: movb %bl, (%rdi)
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: andb $1, %r9b
; SSE42-NEXT: movb %r9b, (%rdi)
; SSE42-NEXT: andb $1, %r11b
; SSE42-NEXT: movb %r11b, (%rdi)
; SSE42-NEXT: andb $1, %r15b
; SSE42-NEXT: movb %r15b, (%rdi)
; SSE42-NEXT: andb $1, %r13b
; SSE42-NEXT: movb %r13b, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %cl
; SSE42-NEXT: movb %cl, (%rdi)
; SSE42-NEXT: andb $1, %dl
; SSE42-NEXT: movb %dl, (%rdi)
; SSE42-NEXT: andb $1, %sil
; SSE42-NEXT: movb %sil, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: andb $1, %bpl
; SSE42-NEXT: movb %bpl, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: popq %rbx
; SSE42-NEXT: popq %r12
; SSE42-NEXT: popq %r13
; SSE42-NEXT: popq %r14
; SSE42-NEXT: popq %r15
; SSE42-NEXT: popq %rbp
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32f64:
; AVX1: # BB#0:
; AVX1-NEXT: pushq %rbp
; AVX1-NEXT: movq %rsp, %rbp
; AVX1-NEXT: andq $-32, %rsp
; AVX1-NEXT: subq $32, %rsp
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vmovapd 16(%rbp), %ymm8
; AVX1-NEXT: vmovapd 48(%rbp), %ymm9
; AVX1-NEXT: vmovapd 80(%rbp), %ymm10
; AVX1-NEXT: vmovapd 112(%rbp), %ymm11
; AVX1-NEXT: vmovapd 144(%rbp), %ymm12
; AVX1-NEXT: vmovapd 176(%rbp), %ymm13
; AVX1-NEXT: vmovapd 208(%rbp), %ymm14
; AVX1-NEXT: vmovapd 240(%rbp), %ymm15
; AVX1-NEXT: vcmpltpd %ymm7, %ymm15, %ymm15
; AVX1-NEXT: vextractf128 $1, %ymm15, %xmm7
; AVX1-NEXT: vpacksswb %xmm7, %xmm15, %xmm15
; AVX1-NEXT: vcmpltpd %ymm6, %ymm14, %ymm6
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm7
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpacksswb %xmm15, %xmm6, %xmm6
; AVX1-NEXT: vcmpltpd %ymm5, %ymm13, %ymm5
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm7
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm7, %xmm5, %xmm5
; AVX1-NEXT: vcmpltpd %ymm4, %ymm12, %ymm4
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm7
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm7, %xmm4, %xmm4
; AVX1-NEXT: vpacksswb %xmm5, %xmm4, %xmm4
; AVX1-NEXT: vpacksswb %xmm6, %xmm4, %xmm4
; AVX1-NEXT: vcmpltpd %ymm3, %ymm11, %ymm3
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm5
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm5, %xmm3, %xmm3
; AVX1-NEXT: vcmpltpd %ymm2, %ymm10, %ymm2
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm5
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm5, %xmm2, %xmm2
; AVX1-NEXT: vpacksswb %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vcmpltpd %ymm1, %ymm9, %ymm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
; AVX1-NEXT: vcmpltpd %ymm0, %ymm8, %ymm0
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm0, %ymm0
; AVX1-NEXT: movq %rbp, %rsp
; AVX1-NEXT: popq %rbp
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v32f64:
; AVX2: # BB#0:
; AVX2-NEXT: pushq %rbp
; AVX2-NEXT: movq %rsp, %rbp
; AVX2-NEXT: andq $-32, %rsp
; AVX2-NEXT: subq $32, %rsp
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vmovapd 16(%rbp), %ymm8
; AVX2-NEXT: vmovapd 48(%rbp), %ymm9
; AVX2-NEXT: vmovapd 80(%rbp), %ymm10
; AVX2-NEXT: vmovapd 112(%rbp), %ymm11
; AVX2-NEXT: vmovapd 144(%rbp), %ymm12
; AVX2-NEXT: vmovapd 176(%rbp), %ymm13
; AVX2-NEXT: vmovapd 208(%rbp), %ymm14
; AVX2-NEXT: vmovapd 240(%rbp), %ymm15
; AVX2-NEXT: vcmpltpd %ymm7, %ymm15, %ymm7
; AVX2-NEXT: vcmpltpd %ymm6, %ymm14, %ymm6
; AVX2-NEXT: vpacksswb %ymm7, %ymm6, %ymm6
; AVX2-NEXT: vpermq {{.*#+}} ymm6 = ymm6[0,2,1,3]
; AVX2-NEXT: vcmpltpd %ymm5, %ymm13, %ymm5
; AVX2-NEXT: vcmpltpd %ymm4, %ymm12, %ymm4
; AVX2-NEXT: vpacksswb %ymm5, %ymm4, %ymm4
; AVX2-NEXT: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm6, %ymm4, %ymm4
; AVX2-NEXT: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
; AVX2-NEXT: vcmpltpd %ymm3, %ymm11, %ymm3
; AVX2-NEXT: vcmpltpd %ymm2, %ymm10, %ymm2
; AVX2-NEXT: vpacksswb %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
; AVX2-NEXT: vcmpltpd %ymm1, %ymm9, %ymm1
; AVX2-NEXT: vcmpltpd %ymm0, %ymm8, %ymm0
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm4, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX2-NEXT: movq %rbp, %rsp
; AVX2-NEXT: popq %rbp
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v32f64:
; AVX512F: # BB#0:
; AVX512F-NEXT: vextractf32x4 $3, %zmm4, %xmm8
; AVX512F-NEXT: vextractf32x4 $3, %zmm0, %xmm9
; AVX512F-NEXT: xorl %eax, %eax
; AVX512F-NEXT: vucomisd %xmm8, %xmm9
; AVX512F-NEXT: movq $-1, %rcx
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm8 = xmm8[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512F-NEXT: vucomisd %xmm8, %xmm9
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm8
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm8 = xmm10[0],xmm8[0]
; AVX512F-NEXT: vextractf32x4 $2, %zmm4, %xmm9
; AVX512F-NEXT: vextractf32x4 $2, %zmm0, %xmm10
; AVX512F-NEXT: vucomisd %xmm9, %xmm10
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm11
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm10 = xmm10[1,0]
; AVX512F-NEXT: vucomisd %xmm9, %xmm10
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm9
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm11[0],xmm9[0]
; AVX512F-NEXT: vinserti128 $1, %xmm8, %ymm9, %ymm8
; AVX512F-NEXT: vextractf32x4 $1, %zmm4, %xmm9
; AVX512F-NEXT: vextractf32x4 $1, %zmm0, %xmm10
; AVX512F-NEXT: vucomisd %xmm9, %xmm10
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm11
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm10 = xmm10[1,0]
; AVX512F-NEXT: vucomisd %xmm9, %xmm10
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm9
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm11[0],xmm9[0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512F-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm8
; AVX512F-NEXT: vextractf32x4 $3, %zmm5, %xmm4
; AVX512F-NEXT: vextractf32x4 $3, %zmm1, %xmm0
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm9
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm0[0]
; AVX512F-NEXT: vextractf32x4 $2, %zmm5, %xmm4
; AVX512F-NEXT: vextractf32x4 $2, %zmm1, %xmm0
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512F-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm9
; AVX512F-NEXT: vextractf32x4 $1, %zmm5, %xmm4
; AVX512F-NEXT: vextractf32x4 $1, %zmm1, %xmm0
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm0
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512F-NEXT: vucomisd %xmm5, %xmm1
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512F-NEXT: vucomisd %xmm5, %xmm1
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm4[0],xmm1[0]
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm9, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm8
; AVX512F-NEXT: vextractf32x4 $3, %zmm6, %xmm1
; AVX512F-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512F-NEXT: vucomisd %xmm1, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vucomisd %xmm1, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512F-NEXT: vextractf32x4 $2, %zmm6, %xmm4
; AVX512F-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512F-NEXT: vucomisd %xmm4, %xmm5
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512F-NEXT: vextractf32x4 $1, %zmm6, %xmm1
; AVX512F-NEXT: vextractf32x4 $1, %zmm2, %xmm4
; AVX512F-NEXT: vucomisd %xmm1, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vucomisd %xmm1, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512F-NEXT: vucomisd %xmm6, %xmm2
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm6[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512F-NEXT: vucomisd %xmm5, %xmm2
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm4[0],xmm2[0]
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm2, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm0
; AVX512F-NEXT: vextractf32x4 $3, %zmm7, %xmm1
; AVX512F-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512F-NEXT: vucomisd %xmm1, %xmm2
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512F-NEXT: vucomisd %xmm1, %xmm2
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm4[0],xmm1[0]
; AVX512F-NEXT: vextractf32x4 $2, %zmm7, %xmm2
; AVX512F-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512F-NEXT: vucomisd %xmm2, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vucomisd %xmm2, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm2, %ymm1
; AVX512F-NEXT: vextractf32x4 $1, %zmm7, %xmm2
; AVX512F-NEXT: vextractf32x4 $1, %zmm3, %xmm4
; AVX512F-NEXT: vucomisd %xmm2, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512F-NEXT: vucomisd %xmm2, %xmm4
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512F-NEXT: vucomisd %xmm7, %xmm3
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovaq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm5 = xmm7[1,0]
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm3 = xmm3[1,0]
; AVX512F-NEXT: vucomisd %xmm5, %xmm3
; AVX512F-NEXT: cmovaq %rcx, %rax
; AVX512F-NEXT: vmovq %rax, %xmm3
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm3 = xmm4[0],xmm3[0]
; AVX512F-NEXT: vinserti128 $1, %xmm2, %ymm3, %ymm2
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm2, %zmm1
; AVX512F-NEXT: vpmovqd %zmm1, %ymm1
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm8, %ymm0
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v32f64:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm4, %xmm8
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm0, %xmm9
; AVX512DQ-NEXT: xorl %eax, %eax
; AVX512DQ-NEXT: vucomisd %xmm8, %xmm9
; AVX512DQ-NEXT: movq $-1, %rcx
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm8 = xmm8[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512DQ-NEXT: vucomisd %xmm8, %xmm9
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm8
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm8 = xmm10[0],xmm8[0]
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm4, %xmm9
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm0, %xmm10
; AVX512DQ-NEXT: vucomisd %xmm9, %xmm10
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm11
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm10 = xmm10[1,0]
; AVX512DQ-NEXT: vucomisd %xmm9, %xmm10
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm9
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm11[0],xmm9[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm8, %ymm9, %ymm8
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm4, %xmm9
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm0, %xmm10
; AVX512DQ-NEXT: vucomisd %xmm9, %xmm10
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm11
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm10 = xmm10[1,0]
; AVX512DQ-NEXT: vucomisd %xmm9, %xmm10
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm9
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm11[0],xmm9[0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm8
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm5, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm1, %xmm0
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm9
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm0[0]
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm5, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm1, %xmm0
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm9
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm5, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm1, %xmm0
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm0
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm1
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm1
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm4[0],xmm1[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm9, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm0
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm0, %zmm8, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm8
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm6, %xmm1
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm2, %xmm4
; AVX512DQ-NEXT: vucomisd %xmm1, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vucomisd %xmm1, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm6, %xmm4
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm2, %xmm5
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512DQ-NEXT: vucomisd %xmm4, %xmm5
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm6, %xmm1
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm2, %xmm4
; AVX512DQ-NEXT: vucomisd %xmm1, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vucomisd %xmm1, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512DQ-NEXT: vucomisd %xmm6, %xmm2
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm6[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm2
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm4[0],xmm2[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm2, %ymm1
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm0
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm7, %xmm1
; AVX512DQ-NEXT: vextractf64x2 $3, %zmm3, %xmm2
; AVX512DQ-NEXT: vucomisd %xmm1, %xmm2
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512DQ-NEXT: vucomisd %xmm1, %xmm2
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm4[0],xmm1[0]
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm7, %xmm2
; AVX512DQ-NEXT: vextractf64x2 $2, %zmm3, %xmm4
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm2, %ymm1
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm7, %xmm2
; AVX512DQ-NEXT: vextractf64x2 $1, %zmm3, %xmm4
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512DQ-NEXT: vucomisd %xmm2, %xmm4
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512DQ-NEXT: vucomisd %xmm7, %xmm3
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovaq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm5 = xmm7[1,0]
; AVX512DQ-NEXT: vpermilpd {{.*#+}} xmm3 = xmm3[1,0]
; AVX512DQ-NEXT: vucomisd %xmm5, %xmm3
; AVX512DQ-NEXT: cmovaq %rcx, %rax
; AVX512DQ-NEXT: vmovq %rax, %xmm3
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm3 = xmm4[0],xmm3[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm2, %ymm3, %ymm2
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm1, %zmm2, %zmm1
; AVX512DQ-NEXT: vpmovqd %zmm1, %ymm1
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm1, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm8, %ymm0
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v32f64:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextractf32x4 $3, %zmm4, %xmm8
; AVX512BW-NEXT: vextractf32x4 $3, %zmm0, %xmm9
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: vucomisd %xmm8, %xmm9
; AVX512BW-NEXT: movq $-1, %rcx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm8 = xmm8[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512BW-NEXT: vucomisd %xmm8, %xmm9
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm8
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm8 = xmm10[0],xmm8[0]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm4, %xmm9
; AVX512BW-NEXT: vextractf32x4 $2, %zmm0, %xmm10
; AVX512BW-NEXT: vucomisd %xmm9, %xmm10
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm11
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm10 = xmm10[1,0]
; AVX512BW-NEXT: vucomisd %xmm9, %xmm10
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm9
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm11[0],xmm9[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm8, %ymm9, %ymm8
; AVX512BW-NEXT: vextractf32x4 $1, %zmm4, %xmm9
; AVX512BW-NEXT: vextractf32x4 $1, %zmm0, %xmm10
; AVX512BW-NEXT: vucomisd %xmm9, %xmm10
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm11
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm9 = xmm9[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm10 = xmm10[1,0]
; AVX512BW-NEXT: vucomisd %xmm9, %xmm10
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm9
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm11[0],xmm9[0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm8
; AVX512BW-NEXT: vextractf32x4 $3, %zmm5, %xmm4
; AVX512BW-NEXT: vextractf32x4 $3, %zmm1, %xmm0
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm9
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm0[0]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm5, %xmm4
; AVX512BW-NEXT: vextractf32x4 $2, %zmm1, %xmm0
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm9
; AVX512BW-NEXT: vextractf32x4 $1, %zmm5, %xmm4
; AVX512BW-NEXT: vextractf32x4 $1, %zmm1, %xmm0
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm0
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm10[0],xmm0[0]
; AVX512BW-NEXT: vucomisd %xmm5, %xmm1
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512BW-NEXT: vucomisd %xmm5, %xmm1
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm4[0],xmm1[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm9, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm8
; AVX512BW-NEXT: vextractf32x4 $3, %zmm6, %xmm1
; AVX512BW-NEXT: vextractf32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vucomisd %xmm1, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vucomisd %xmm1, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm6, %xmm4
; AVX512BW-NEXT: vextractf32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm5[1,0]
; AVX512BW-NEXT: vucomisd %xmm4, %xmm5
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512BW-NEXT: vextractf32x4 $1, %zmm6, %xmm1
; AVX512BW-NEXT: vextractf32x4 $1, %zmm2, %xmm4
; AVX512BW-NEXT: vucomisd %xmm1, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vucomisd %xmm1, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm5[0],xmm1[0]
; AVX512BW-NEXT: vucomisd %xmm6, %xmm2
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm6[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512BW-NEXT: vucomisd %xmm5, %xmm2
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm4[0],xmm2[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm1, %ymm2, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm0
; AVX512BW-NEXT: vextractf32x4 $3, %zmm7, %xmm1
; AVX512BW-NEXT: vextractf32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vucomisd %xmm1, %xmm2
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512BW-NEXT: vucomisd %xmm1, %xmm2
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm4[0],xmm1[0]
; AVX512BW-NEXT: vextractf32x4 $2, %zmm7, %xmm2
; AVX512BW-NEXT: vextractf32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vucomisd %xmm2, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vucomisd %xmm2, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm1, %ymm2, %ymm1
; AVX512BW-NEXT: vextractf32x4 $1, %zmm7, %xmm2
; AVX512BW-NEXT: vextractf32x4 $1, %zmm3, %xmm4
; AVX512BW-NEXT: vucomisd %xmm2, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm4 = xmm4[1,0]
; AVX512BW-NEXT: vucomisd %xmm2, %xmm4
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm5[0],xmm2[0]
; AVX512BW-NEXT: vucomisd %xmm7, %xmm3
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovaq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm5 = xmm7[1,0]
; AVX512BW-NEXT: vpermilpd {{.*#+}} xmm3 = xmm3[1,0]
; AVX512BW-NEXT: vucomisd %xmm5, %xmm3
; AVX512BW-NEXT: cmovaq %rcx, %rax
; AVX512BW-NEXT: vmovq %rax, %xmm3
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm3 = xmm4[0],xmm3[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm2, %ymm3, %ymm2
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm2, %zmm1
; AVX512BW-NEXT: vpmovqd %zmm1, %ymm1
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: retq
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
%1 = fcmp ogt <32 x double> %a0, %a1
ret <32 x i1> %1
}
define <32 x i1> @test_cmp_v32i64(<32 x i64> %a0, <32 x i64> %a1) nounwind {
; SSE2-LABEL: test_cmp_v32i64:
; SSE2: # BB#0:
; SSE2-NEXT: movdqa {{.*#+}} xmm8 = [2147483648,0,2147483648,0]
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm9
; SSE2-NEXT: pxor %xmm8, %xmm9
; SSE2-NEXT: movdqa %xmm7, %xmm10
; SSE2-NEXT: pcmpgtd %xmm9, %xmm10
; SSE2-NEXT: pshufd {{.*#+}} xmm11 = xmm10[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm7, %xmm9
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm9[1,1,3,3]
; SSE2-NEXT: pand %xmm11, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm10[1,1,3,3]
; SSE2-NEXT: por %xmm7, %xmm9
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm6
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: movdqa %xmm6, %xmm10
; SSE2-NEXT: pcmpgtd %xmm7, %xmm10
; SSE2-NEXT: pshufd {{.*#+}} xmm11 = xmm10[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm6, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm7[1,1,3,3]
; SSE2-NEXT: pand %xmm11, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm10[1,1,3,3]
; SSE2-NEXT: por %xmm6, %xmm7
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm7 = xmm7[0,2],xmm9[0,2]
; SSE2-NEXT: pslld $31, %xmm7
; SSE2-NEXT: psrad $31, %xmm7
; SSE2-NEXT: pshuflw {{.*#+}} xmm6 = xmm7[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm6 = xmm6[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm6[0,2,2,3]
; SSE2-NEXT: pxor %xmm8, %xmm5
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: movdqa %xmm5, %xmm6
; SSE2-NEXT: pcmpgtd %xmm7, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm10 = xmm6[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm5, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm7[1,1,3,3]
; SSE2-NEXT: pand %xmm10, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm6[1,1,3,3]
; SSE2-NEXT: por %xmm5, %xmm6
; SSE2-NEXT: pxor %xmm8, %xmm4
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pxor %xmm8, %xmm5
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movdqa %xmm4, %xmm7
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm5, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm10 = xmm7[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm4, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
; SSE2-NEXT: pand %xmm10, %xmm4
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm7[1,1,3,3]
; SSE2-NEXT: por %xmm4, %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: shufps {{.*#+}} xmm5 = xmm5[0,2],xmm6[0,2]
; SSE2-NEXT: pslld $31, %xmm5
; SSE2-NEXT: psrad $31, %xmm5
; SSE2-NEXT: pshuflw {{.*#+}} xmm4 = xmm5[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm4 = xmm4[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm5 = xmm5[0],xmm9[0]
; SSE2-NEXT: psllw $15, %xmm5
; SSE2-NEXT: psraw $15, %xmm5
; SSE2-NEXT: movdqa {{.*#+}} xmm9 = [255,255,255,255,255,255,255,255]
; SSE2-NEXT: pand %xmm9, %xmm5
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: pxor %xmm8, %xmm6
; SSE2-NEXT: movdqa %xmm3, %xmm7
; SSE2-NEXT: pcmpgtd %xmm6, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm7[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm3, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm6[1,1,3,3]
; SSE2-NEXT: pand %xmm4, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm7[1,1,3,3]
; SSE2-NEXT: por %xmm3, %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm2
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movdqa %xmm2, %xmm6
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm3, %xmm6
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm7 = xmm6[0,0,2,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpeqd %xmm2, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pand %xmm7, %xmm2
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm6[1,1,3,3]
; SSE2-NEXT: por %xmm2, %xmm3
; SSE2-NEXT: shufps {{.*#+}} xmm3 = xmm3[0,2],xmm4[0,2]
; SSE2-NEXT: pslld $31, %xmm3
; SSE2-NEXT: psrad $31, %xmm3
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm3[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: pxor %xmm8, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm1, %xmm4
; SSE2-NEXT: pcmpgtd %xmm3, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm4[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm1, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm0
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movdqa %xmm0, %xmm4
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm1, %xmm4
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm4[0,0,2,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pand %xmm6, %xmm0
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm1
; SSE2-NEXT: shufps {{.*#+}} xmm1 = xmm1[0,2],xmm3[0,2]
; SSE2-NEXT: pslld $31, %xmm1
; SSE2-NEXT: psrad $31, %xmm1
; SSE2-NEXT: pshuflw {{.*#+}} xmm0 = xmm1[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm2[0]
; SSE2-NEXT: psllw $15, %xmm0
; SSE2-NEXT: psraw $15, %xmm0
; SSE2-NEXT: pand %xmm9, %xmm0
; SSE2-NEXT: packuswb %xmm5, %xmm0
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pxor %xmm8, %xmm2
; SSE2-NEXT: movdqa %xmm2, %xmm3
; SSE2-NEXT: pcmpgtd %xmm1, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm3[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm1, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
; SSE2-NEXT: pand %xmm4, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm2
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm3, %xmm4
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm1, %xmm4
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpeqd %xmm1, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: por %xmm1, %xmm3
; SSE2-NEXT: shufps {{.*#+}} xmm3 = xmm3[0,2],xmm2[0,2]
; SSE2-NEXT: pslld $31, %xmm3
; SSE2-NEXT: psrad $31, %xmm3
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm3[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm1[0,2,2,3]
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm3, %xmm4
; SSE2-NEXT: pcmpgtd %xmm1, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm1, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm3
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa %xmm4, %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm1, %xmm5
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpeqd %xmm1, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm4[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: por %xmm1, %xmm4
; SSE2-NEXT: shufps {{.*#+}} xmm4 = xmm4[0,2],xmm3[0,2]
; SSE2-NEXT: pslld $31, %xmm4
; SSE2-NEXT: psrad $31, %xmm4
; SSE2-NEXT: pshuflw {{.*#+}} xmm1 = xmm4[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSE2-NEXT: psllw $15, %xmm1
; SSE2-NEXT: psraw $15, %xmm1
; SSE2-NEXT: pand %xmm9, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pxor %xmm8, %xmm2
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa %xmm3, %xmm4
; SSE2-NEXT: pcmpgtd %xmm2, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm2, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm2, %xmm3
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pxor %xmm8, %xmm2
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa %xmm4, %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm2, %xmm5
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpeqd %xmm2, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm4[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm2
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: por %xmm2, %xmm4
; SSE2-NEXT: shufps {{.*#+}} xmm4 = xmm4[0,2],xmm3[0,2]
; SSE2-NEXT: pslld $31, %xmm4
; SSE2-NEXT: psrad $31, %xmm4
; SSE2-NEXT: pshuflw {{.*#+}} xmm2 = xmm4[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm2 = xmm2[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[0,2,2,3]
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa %xmm4, %xmm5
; SSE2-NEXT: pcmpgtd %xmm3, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm3, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
; SSE2-NEXT: por %xmm3, %xmm4
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pxor %xmm8, %xmm3
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pxor {{[0-9]+}}(%rsp), %xmm8
; SSE2-NEXT: movdqa %xmm8, %xmm5
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpgtd %xmm3, %xmm5
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: pcmpeqd %xmm3, %xmm8
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm8[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm3
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm5[1,1,3,3]
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE2-NEXT: por %xmm3, %xmm5
; SSE2-NEXT: shufps {{.*#+}} xmm5 = xmm5[0,2],xmm4[0,2]
; SSE2-NEXT: pslld $31, %xmm5
; SSE2-NEXT: psrad $31, %xmm5
; SSE2-NEXT: pshuflw {{.*#+}} xmm3 = xmm5[0,2,2,3,4,5,6,7]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: pshufhw {{.*#+}} xmm3 = xmm3[0,1,2,3,4,6,6,7]
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[0,2,2,3]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm3 = xmm3[0],xmm2[0]
; SSE2-NEXT: psllw $15, %xmm3
; SSE2-NEXT: psraw $15, %xmm3
; SSE2-NEXT: pand %xmm9, %xmm3
; SSE2-NEXT: packuswb %xmm1, %xmm3
; SSE2-NEXT: movdqa %xmm3, -{{[0-9]+}}(%rsp)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, nhaehnle, jyknight Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 282600
2016-09-28 23:50:43 +08:00
; SSE2-NEXT: movb %al, (%rdi)
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after upstream changes. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. CodeGen/AMDGPU/vgpr-spill-emergency-stack-slot-compute.ll - This test appears to work but no longer exhibits the spill behavior. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 284151
2016-10-14 03:20:16 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r282600 due to test failues with MCJIT llvm-svn: 282604
2016-09-29 00:37:50 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing overly aggressive load-store forwarding optimization. Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289221
2016-12-10 00:15:12 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r284151 which appears to be triggering a LTO failures on Hexagon llvm-svn: 284157
2016-10-14 04:23:25 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Retrying after fixing after removing load-store factoring through token factors in favor of improved token factor operand pruning Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. Whem merging stores, search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and generally the output CodeGen (with some exceptions). Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seemed sufficient to not cause regressions in tests. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable. Some tests relying on the order were changed to use volatile memory operations Noteworthy tests: CodeGen/AArch64/argument-blocks.ll - It's not entirely clear what the test_varargs_stackalign test is supposed to be asserting, but the new code looks right. CodeGen/AArch64/arm64-memset-inline.lli - CodeGen/AArch64/arm64-stur.ll - CodeGen/ARM/memset-inline.ll - The backend now generates *worse* code due to store merging succeeding, as we do do a 16-byte constant-zero store efficiently. CodeGen/AArch64/merge-store.ll - Improved, but there still seems to be an extraneous vector insert from an element to itself? CodeGen/PowerPC/ppc64-align-long-double.ll - Worse code emitted in this case, due to the improved store->load forwarding. CodeGen/X86/dag-merge-fast-accesses.ll - CodeGen/X86/MergeConsecutiveStores.ll - CodeGen/X86/stores-merging.ll - CodeGen/Mips/load-store-left-right.ll - Restored correct merging of non-aligned stores CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll - Improved. Correctly merges buffer_store_dword calls CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll - Improved. Sidesteps loading a stored value and merges two stores CodeGen/X86/pr18023.ll - This test has been removed, as it was asserting incorrect behavior. Non-volatile stores *CAN* be moved past volatile loads, and now are. CodeGen/X86/vector-idiv.ll - CodeGen/X86/vector-lzcnt-128.ll - It's basically impossible to tell what these tests are actually testing. But, looks like the code got better due to the memory operations being recognized as non-aliasing. CodeGen/X86/win32-eh.ll - Both loads of the securitycookie are now merged. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel Differential Revision: https://reviews.llvm.org/D14834 llvm-svn: 289659
2016-12-14 23:44:26 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r289221 which appears to be triggering an assertion llvm-svn: 289226
2016-12-10 01:18:24 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293184
2017-01-27 00:02:24 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." Reverting due to ARM MCJIT and MIPS LLD error. This reverts commit r289659. llvm-svn: 289667
2016-12-15 00:43:44 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixing X86 inc/dec chain bug. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 293893
2017-02-02 22:39:42 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293184 which is failing in LTO builds llvm-svn: 293188
2017-01-27 00:46:13 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296252
2017-02-25 19:43:58 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r293893 which is miscompiling lua on ARM and bootstrapping for x86-windows. llvm-svn: 293915
2017-02-03 02:24:55 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: andb $1, %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
; SSE2-NEXT: andb $1, %al
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner. * Simplify Consecutive Merge Store Candidate Search Now that address aliasing is much less conservative, push through simplified store merging search and chain alias analysis which only checks for parallel stores through the chain subgraph. This is cleaner as the separation of non-interfering loads/stores from the store-merging logic. When merging stores search up the chain through a single load, and finds all possible stores by looking down from through a load and a TokenFactor to all stores visited. This improves the quality of the output SelectionDAG and the output Codegen (save perhaps for some ARM cases where we correctly constructs wider loads, but then promotes them to float operations which appear but requires more expensive constant generation). Some minor peephole optimizations to deal with improved SubDAG shapes (listed below) Additional Minor Changes: 1. Finishes removing unused AliasLoad code 2. Unifies the chain aggregation in the merged stores across code paths 3. Re-add the Store node to the worklist after calling SimplifyDemandedBits. 4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is arbitrary, but seems sufficient to not cause regressions in tests. 5. Remove Chain dependencies of Memory operations on CopyfromReg nodes as these are captured by data dependence 6. Forward loads-store values through tokenfactors containing {CopyToReg,CopyFromReg} Values. 7. Peephole to convert buildvector of extract_vector_elt to extract_subvector if possible (see CodeGen/AArch64/store-merge.ll) 8. Store merging for the ARM target is restricted to 32-bit as some in some contexts invalid 64-bit operations are being generated. This can be removed once appropriate checks are added. This finishes the change Matt Arsenault started in r246307 and jyknight's original patch. Many tests required some changes as memory operations are now reorderable, improving load-store forwarding. One test in particular is worth noting: CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store forwarding converts a load-store pair into a parallel store and a memory-realized bitcast of the same value. However, because we lose the sharing of the explicit and implicit store values we must create another local store. A similar transformation happens before SelectionDAG as well. Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle llvm-svn: 296476
2017-02-28 22:24:15 +08:00
; SSE2-NEXT: movb %al, (%rdi)
Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled." This reverts commit r296252 until 256-bit operations are more efficiently generated in X86. llvm-svn: 296279
2017-02-26 09:27:32 +08:00
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[SDAG] Revert r296476 (and r296486, r296668, r296690). This patch causes compile times for some patterns to explode. I have a (large, unreduced) test case that slows down by more than 20x and several test cases slow down by 2x. I'm sending some of the test cases directly to Nirav and following up with more details in the review log, but this should unblock anyone else hitting this. llvm-svn: 296862
2017-03-03 18:02:25 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, 2(%rdi)
; SSE2-NEXT: movb -{{[0-9]+}}(%rsp), %al
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE2-NEXT: andb $1, %al
; SSE2-NEXT: movb %al, (%rdi)
; SSE2-NEXT: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i64:
; SSE42: # BB#0:
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm9
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm11
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm10
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm12
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm8
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm14
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm13
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm15
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm2
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: shufps {{.*#+}} xmm2 = xmm2[0,2],xmm3[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: pslld $31, %xmm2
; SSE42-NEXT: psrad $31, %xmm2
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: movdqa {{.*#+}} xmm3 = [0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; SSE42-NEXT: pshufb %xmm3, %xmm2
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: pslld $31, %xmm0
; SSE42-NEXT: psrad $31, %xmm0
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pshufb %xmm3, %xmm0
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm2[0]
; SSE42-NEXT: psllw $15, %xmm0
; SSE42-NEXT: psraw $15, %xmm0
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: shufps {{.*#+}} xmm6 = xmm6[0,2],xmm7[0,2]
; SSE42-NEXT: pslld $31, %xmm6
; SSE42-NEXT: psrad $31, %xmm6
; SSE42-NEXT: pshufb %xmm3, %xmm6
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: shufps {{.*#+}} xmm4 = xmm4[0,2],xmm5[0,2]
; SSE42-NEXT: pslld $31, %xmm4
; SSE42-NEXT: psrad $31, %xmm4
; SSE42-NEXT: pshufb %xmm3, %xmm4
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm4 = xmm4[0],xmm6[0]
; SSE42-NEXT: psllw $15, %xmm4
; SSE42-NEXT: psraw $15, %xmm4
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm15
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm13
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: shufps {{.*#+}} xmm13 = xmm13[0,2],xmm15[0,2]
; SSE42-NEXT: pslld $31, %xmm13
; SSE42-NEXT: psrad $31, %xmm13
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pshufb %xmm3, %xmm13
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm14
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm8
; SSE42-NEXT: shufps {{.*#+}} xmm8 = xmm8[0,2],xmm14[0,2]
; SSE42-NEXT: pslld $31, %xmm8
; SSE42-NEXT: psrad $31, %xmm8
; SSE42-NEXT: pshufb %xmm3, %xmm8
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm8 = xmm8[0],xmm13[0]
; SSE42-NEXT: psllw $15, %xmm8
; SSE42-NEXT: psraw $15, %xmm8
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm12
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm10
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: shufps {{.*#+}} xmm10 = xmm10[0,2],xmm12[0,2]
; SSE42-NEXT: pslld $31, %xmm10
; SSE42-NEXT: psrad $31, %xmm10
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pshufb %xmm3, %xmm10
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm11
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm9
; SSE42-NEXT: shufps {{.*#+}} xmm9 = xmm9[0,2],xmm11[0,2]
; SSE42-NEXT: pslld $31, %xmm9
; SSE42-NEXT: psrad $31, %xmm9
; SSE42-NEXT: pshufb %xmm3, %xmm9
; SSE42-NEXT: punpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm10[0]
; SSE42-NEXT: psllw $15, %xmm9
; SSE42-NEXT: psraw $15, %xmm9
; SSE42-NEXT: pextrb $14, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm9, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; SSE42-NEXT: pextrb $0, %xmm8, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, 2(%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $0, %xmm4, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $14, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $12, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $10, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $6, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $4, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
[X86][SSE] Attempt to extract vector elements through target shuffles DAGCombiner already supports peeking thorough shuffles to improve vector element extraction, but legalization often leaves us in situations where we need to extract vector elements after shuffles have already been lowered. This patch adds support for VECTOR_EXTRACT_ELEMENT/PEXTRW/PEXTRB instructions to attempt to handle target shuffles as well. I've covered some basic scenarios including handling shuffle mask scaling and the implicit zero-extension of PEXTRW/PEXTRB, there is more that could be done here (that I've mentioned in TODOs) but I haven't found many cases where its worth it. Differential Revision: https://reviews.llvm.org/D30176 llvm-svn: 296381
2017-02-28 05:01:57 +08:00
; SSE42-NEXT: pextrb $2, %xmm0, %eax
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: andb $1, %al
; SSE42-NEXT: movb %al, (%rdi)
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i64:
; AVX1: # BB#0:
; AVX1-NEXT: pushq %rbp
; AVX1-NEXT: movq %rsp, %rbp
; AVX1-NEXT: andq $-32, %rsp
; AVX1-NEXT: subq $32, %rsp
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 240(%rbp), %ymm8
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm8, %xmm9
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm10
; AVX1-NEXT: vpcmpgtq %xmm9, %xmm10, %xmm9
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 208(%rbp), %ymm10
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpcmpgtq %xmm8, %xmm7, %xmm7
; AVX1-NEXT: vpacksswb %xmm9, %xmm7, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm10, %xmm9
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm7
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpcmpgtq %xmm9, %xmm7, %xmm7
; AVX1-NEXT: vpcmpgtq %xmm10, %xmm6, %xmm6
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 176(%rbp), %ymm9
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpacksswb %xmm8, %xmm6, %xmm8
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm9, %xmm7
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm6
; AVX1-NEXT: vpcmpgtq %xmm7, %xmm6, %xmm6
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 144(%rbp), %ymm10
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vpcmpgtq %xmm9, %xmm5, %xmm5
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm6, %xmm5, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm10, %xmm6
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm7
; AVX1-NEXT: vpcmpgtq %xmm6, %xmm7, %xmm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpcmpgtq %xmm10, %xmm4, %xmm4
; AVX1-NEXT: vpacksswb %xmm6, %xmm4, %xmm4
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 112(%rbp), %ymm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm5, %xmm4, %xmm4
; AVX1-NEXT: vpacksswb %xmm8, %xmm4, %xmm4
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm7
; AVX1-NEXT: vpcmpgtq %xmm5, %xmm7, %xmm5
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 80(%rbp), %ymm7
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vpcmpgtq %xmm6, %xmm3, %xmm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm5, %xmm3, %xmm3
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm6
; AVX1-NEXT: vpcmpgtq %xmm5, %xmm6, %xmm5
; AVX1-NEXT: vpcmpgtq %xmm7, %xmm2, %xmm2
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 48(%rbp), %ymm6
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm5, %xmm2, %xmm2
; AVX1-NEXT: vpacksswb %xmm3, %xmm2, %xmm2
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm5, %xmm3
[X86] Don't base domain decisions on VEXTRACTF128/VINSERTF128 if only AVX1 is available. Seems the execution dependency pass likes to use FP instructions when most of the consuming code is integer if a vextractf128 instruction produced the register. Without AVX2 we don't have the corresponding integer instruction available. This patch suppresses the domain on these instructions to GenericDomain if AVX2 is not supported so that they are ignored by domain fixing. If AVX2 is supported we'll report the correct domain and allow them to switch between integer and fp. Overall I think this produces better results in the modified test cases. llvm-svn: 294824
2017-02-11 13:32:57 +08:00
; AVX1-NEXT: vmovdqa 16(%rbp), %ymm5
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vpcmpgtq %xmm6, %xmm1, %xmm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm1, %xmm1
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm3
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm6
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm6, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm5, %xmm0, %xmm0
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX1-NEXT: vpacksswb %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm4, %ymm0, %ymm0
; AVX1-NEXT: movq %rbp, %rsp
; AVX1-NEXT: popq %rbp
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v32i64:
; AVX2: # BB#0:
; AVX2-NEXT: pushq %rbp
; AVX2-NEXT: movq %rsp, %rbp
; AVX2-NEXT: andq $-32, %rsp
; AVX2-NEXT: subq $32, %rsp
; AVX2-NEXT: vpcmpgtq 240(%rbp), %ymm7, %ymm7
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq 208(%rbp), %ymm6, %ymm6
; AVX2-NEXT: vpacksswb %ymm7, %ymm6, %ymm6
; AVX2-NEXT: vpermq {{.*#+}} ymm6 = ymm6[0,2,1,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX2-NEXT: vpcmpgtq 176(%rbp), %ymm5, %ymm5
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq 144(%rbp), %ymm4, %ymm4
; AVX2-NEXT: vpacksswb %ymm5, %ymm4, %ymm4
; AVX2-NEXT: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm6, %ymm4, %ymm4
; AVX2-NEXT: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX2-NEXT: vpcmpgtq 112(%rbp), %ymm3, %ymm3
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq 80(%rbp), %ymm2, %ymm2
; AVX2-NEXT: vpacksswb %ymm3, %ymm2, %ymm2
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX2-NEXT: vpcmpgtq 48(%rbp), %ymm1, %ymm1
[X86][SSE] Optimize the truncation of vector comparison results with PACKSS We currently default to using either generic shuffles or MASK+PACKUS/PACKSS to truncate all integer vectors. For vector comparisons, we know that the result will be either all or zero bits in every element, which can be efficiently truncated by directly using PACKSS to repeatedly halve the size of each element. Due to the limited input values (-1 or 0) we don't need to account for vector element size, so for simplicity we just use the PACKSS(vXi16,vXi16) implementation in all cases. Additionally for AVX2 PACKSS of 256bit data we must perform a PERMQ shuffle to reorder the data into the correct order. I did investigate performing a single shuffle after all the PACKSS calls but the need to cross 128bit lanes makes this difficult to achieve efficiently. We avoid performing this on AVX512 as it should have better alternative truncation instructions. Differential Revision: https://reviews.llvm.org/D22814 llvm-svn: 277132
2016-07-29 18:23:10 +08:00
; AVX2-NEXT: vpcmpgtq 16(%rbp), %ymm0, %ymm0
; AVX2-NEXT: vpacksswb %ymm1, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vpacksswb %ymm4, %ymm0, %ymm0
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
; AVX2-NEXT: movq %rbp, %rsp
; AVX2-NEXT: popq %rbp
; AVX2-NEXT: retq
;
[X86] Add avx512bw and avx512dq command lines to the vector compare results test. This is preparation for improving a case with avx512dq. llvm-svn: 291401
2017-01-09 05:32:26 +08:00
; AVX512F-LABEL: test_cmp_v32i64:
; AVX512F: # BB#0:
; AVX512F-NEXT: vextracti32x4 $3, %zmm4, %xmm8
; AVX512F-NEXT: vpextrq $1, %xmm8, %rcx
; AVX512F-NEXT: vextracti32x4 $3, %zmm0, %xmm9
; AVX512F-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512F-NEXT: xorl %eax, %eax
; AVX512F-NEXT: cmpq %rcx, %rdx
; AVX512F-NEXT: movq $-1, %rcx
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vmovq %xmm8, %rdx
; AVX512F-NEXT: vmovq %xmm9, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm8
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm8 = xmm8[0],xmm10[0]
; AVX512F-NEXT: vextracti32x4 $2, %zmm4, %xmm9
; AVX512F-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512F-NEXT: vextracti32x4 $2, %zmm0, %xmm10
; AVX512F-NEXT: vpextrq $1, %xmm10, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm11
; AVX512F-NEXT: vmovq %xmm9, %rdx
; AVX512F-NEXT: vmovq %xmm10, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm9
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm11[0]
; AVX512F-NEXT: vinserti128 $1, %xmm8, %ymm9, %ymm8
; AVX512F-NEXT: vextracti32x4 $1, %zmm4, %xmm9
; AVX512F-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512F-NEXT: vextracti32x4 $1, %zmm0, %xmm10
; AVX512F-NEXT: vpextrq $1, %xmm10, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm11
; AVX512F-NEXT: vmovq %xmm9, %rdx
; AVX512F-NEXT: vmovq %xmm10, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm9
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm11[0]
; AVX512F-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512F-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512F-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm8
; AVX512F-NEXT: vextracti32x4 $3, %zmm5, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512F-NEXT: vextracti32x4 $3, %zmm1, %xmm0
; AVX512F-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm9
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm0[0],xmm9[0]
; AVX512F-NEXT: vextracti32x4 $2, %zmm5, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512F-NEXT: vextracti32x4 $2, %zmm1, %xmm0
; AVX512F-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm0, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512F-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm9
; AVX512F-NEXT: vextracti32x4 $1, %zmm5, %xmm0
; AVX512F-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512F-NEXT: vextracti32x4 $1, %zmm1, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm10
; AVX512F-NEXT: vmovq %xmm0, %rdx
; AVX512F-NEXT: vmovq %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512F-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512F-NEXT: vpextrq $1, %xmm1, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vmovq %xmm5, %rdx
; AVX512F-NEXT: vmovq %xmm1, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm4[0]
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm9, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm8
; AVX512F-NEXT: vextracti32x4 $3, %zmm6, %xmm1
; AVX512F-NEXT: vpextrq $1, %xmm1, %rdx
; AVX512F-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vmovq %xmm1, %rdx
; AVX512F-NEXT: vmovq %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm1
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm5[0]
; AVX512F-NEXT: vextracti32x4 $2, %zmm6, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512F-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512F-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vmovq %xmm4, %rdx
; AVX512F-NEXT: vmovq %xmm5, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm4[0],xmm0[0]
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm1
; AVX512F-NEXT: vextracti32x4 $1, %zmm6, %xmm0
; AVX512F-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512F-NEXT: vextracti32x4 $1, %zmm2, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vmovq %xmm0, %rdx
; AVX512F-NEXT: vmovq %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm5[0]
; AVX512F-NEXT: vpextrq $1, %xmm6, %rdx
; AVX512F-NEXT: vpextrq $1, %xmm2, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vmovq %xmm6, %rdx
; AVX512F-NEXT: vmovq %xmm2, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm4[0]
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm2, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm1
; AVX512F-NEXT: vextracti32x4 $3, %zmm7, %xmm0
; AVX512F-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512F-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512F-NEXT: vpextrq $1, %xmm2, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vmovq %xmm0, %rdx
; AVX512F-NEXT: vmovq %xmm2, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; AVX512F-NEXT: vextracti32x4 $2, %zmm7, %xmm2
; AVX512F-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512F-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vmovq %xmm2, %rdx
; AVX512F-NEXT: vmovq %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm2
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm5[0]
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm2, %ymm2
; AVX512F-NEXT: vextracti32x4 $1, %zmm7, %xmm0
; AVX512F-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512F-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm5
; AVX512F-NEXT: vmovq %xmm0, %rdx
; AVX512F-NEXT: vmovq %xmm4, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm5[0]
; AVX512F-NEXT: vpextrq $1, %xmm7, %rdx
; AVX512F-NEXT: vpextrq $1, %xmm3, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: movl $0, %edx
; AVX512F-NEXT: cmovgq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm4
; AVX512F-NEXT: vmovq %xmm7, %rdx
; AVX512F-NEXT: vmovq %xmm3, %rsi
; AVX512F-NEXT: cmpq %rdx, %rsi
; AVX512F-NEXT: cmovgq %rcx, %rax
; AVX512F-NEXT: vmovq %rax, %xmm3
; AVX512F-NEXT: vpunpcklqdq {{.*#+}} xmm3 = xmm3[0],xmm4[0]
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm3, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
; AVX512F-NEXT: vpmovqd %zmm0, %ymm0
; AVX512F-NEXT: vinserti64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vinserti128 $1, %xmm0, %ymm8, %ymm0
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v32i64:
; AVX512DQ: # BB#0:
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm4, %xmm8
; AVX512DQ-NEXT: vpextrq $1, %xmm8, %rcx
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm0, %xmm9
; AVX512DQ-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512DQ-NEXT: xorl %eax, %eax
; AVX512DQ-NEXT: cmpq %rcx, %rdx
; AVX512DQ-NEXT: movq $-1, %rcx
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vmovq %xmm8, %rdx
; AVX512DQ-NEXT: vmovq %xmm9, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm8
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm8 = xmm8[0],xmm10[0]
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm4, %xmm9
; AVX512DQ-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm0, %xmm10
; AVX512DQ-NEXT: vpextrq $1, %xmm10, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm11
; AVX512DQ-NEXT: vmovq %xmm9, %rdx
; AVX512DQ-NEXT: vmovq %xmm10, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm9
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm11[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm8, %ymm9, %ymm8
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm4, %xmm9
; AVX512DQ-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm0, %xmm10
; AVX512DQ-NEXT: vpextrq $1, %xmm10, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm11
; AVX512DQ-NEXT: vmovq %xmm9, %rdx
; AVX512DQ-NEXT: vmovq %xmm10, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm9
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm11[0]
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm8
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm5, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm1, %xmm0
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm9
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm0[0],xmm9[0]
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm5, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm1, %xmm0
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm0, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm9
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm5, %xmm0
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm1, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm10
; AVX512DQ-NEXT: vmovq %xmm0, %rdx
; AVX512DQ-NEXT: vmovq %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512DQ-NEXT: vpextrq $1, %xmm1, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vmovq %xmm5, %rdx
; AVX512DQ-NEXT: vmovq %xmm1, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm4[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm9, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm0
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm0, %zmm8, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm8
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm6, %xmm1
; AVX512DQ-NEXT: vpextrq $1, %xmm1, %rdx
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm2, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vmovq %xmm1, %rdx
; AVX512DQ-NEXT: vmovq %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm1
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm5[0]
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm6, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm2, %xmm5
; AVX512DQ-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vmovq %xmm4, %rdx
; AVX512DQ-NEXT: vmovq %xmm5, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm4[0],xmm0[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm1
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm6, %xmm0
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm2, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vmovq %xmm0, %rdx
; AVX512DQ-NEXT: vmovq %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm5[0]
; AVX512DQ-NEXT: vpextrq $1, %xmm6, %rdx
; AVX512DQ-NEXT: vpextrq $1, %xmm2, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vmovq %xmm6, %rdx
; AVX512DQ-NEXT: vmovq %xmm2, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm4[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm2, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm1
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm7, %xmm0
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512DQ-NEXT: vextracti64x2 $3, %zmm3, %xmm2
; AVX512DQ-NEXT: vpextrq $1, %xmm2, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vmovq %xmm0, %rdx
; AVX512DQ-NEXT: vmovq %xmm2, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm7, %xmm2
; AVX512DQ-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512DQ-NEXT: vextracti64x2 $2, %zmm3, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vmovq %xmm2, %rdx
; AVX512DQ-NEXT: vmovq %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm2
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm5[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm2, %ymm2
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm7, %xmm0
; AVX512DQ-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512DQ-NEXT: vextracti64x2 $1, %zmm3, %xmm4
; AVX512DQ-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm5
; AVX512DQ-NEXT: vmovq %xmm0, %rdx
; AVX512DQ-NEXT: vmovq %xmm4, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm0
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm5[0]
; AVX512DQ-NEXT: vpextrq $1, %xmm7, %rdx
; AVX512DQ-NEXT: vpextrq $1, %xmm3, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: movl $0, %edx
; AVX512DQ-NEXT: cmovgq %rcx, %rdx
; AVX512DQ-NEXT: vmovq %rdx, %xmm4
; AVX512DQ-NEXT: vmovq %xmm7, %rdx
; AVX512DQ-NEXT: vmovq %xmm3, %rsi
; AVX512DQ-NEXT: cmpq %rdx, %rsi
; AVX512DQ-NEXT: cmovgq %rcx, %rax
; AVX512DQ-NEXT: vmovq %rax, %xmm3
; AVX512DQ-NEXT: vpunpcklqdq {{.*#+}} xmm3 = xmm3[0],xmm4[0]
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm3, %ymm0
; AVX512DQ-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
; AVX512DQ-NEXT: vpmovqd %zmm0, %ymm0
; AVX512DQ-NEXT: vinserti32x8 $1, %ymm0, %zmm1, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vinserti128 $1, %xmm0, %ymm8, %ymm0
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v32i64:
; AVX512BW: # BB#0:
; AVX512BW-NEXT: vextracti32x4 $3, %zmm4, %xmm8
; AVX512BW-NEXT: vpextrq $1, %xmm8, %rcx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm0, %xmm9
; AVX512BW-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512BW-NEXT: xorl %eax, %eax
; AVX512BW-NEXT: cmpq %rcx, %rdx
; AVX512BW-NEXT: movq $-1, %rcx
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vmovq %xmm8, %rdx
; AVX512BW-NEXT: vmovq %xmm9, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm8
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm8 = xmm8[0],xmm10[0]
; AVX512BW-NEXT: vextracti32x4 $2, %zmm4, %xmm9
; AVX512BW-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm0, %xmm10
; AVX512BW-NEXT: vpextrq $1, %xmm10, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm11
; AVX512BW-NEXT: vmovq %xmm9, %rdx
; AVX512BW-NEXT: vmovq %xmm10, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm9
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm11[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm8, %ymm9, %ymm8
; AVX512BW-NEXT: vextracti32x4 $1, %zmm4, %xmm9
; AVX512BW-NEXT: vpextrq $1, %xmm9, %rdx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm0, %xmm10
; AVX512BW-NEXT: vpextrq $1, %xmm10, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm11
; AVX512BW-NEXT: vmovq %xmm9, %rdx
; AVX512BW-NEXT: vmovq %xmm10, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm9
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm9[0],xmm11[0]
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm8, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm8
; AVX512BW-NEXT: vextracti32x4 $3, %zmm5, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm1, %xmm0
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm9
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm9 = xmm0[0],xmm9[0]
; AVX512BW-NEXT: vextracti32x4 $2, %zmm5, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm1, %xmm0
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm0, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm9, %ymm0, %ymm9
; AVX512BW-NEXT: vextracti32x4 $1, %zmm5, %xmm0
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm1, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm10
; AVX512BW-NEXT: vmovq %xmm0, %rdx
; AVX512BW-NEXT: vmovq %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm10[0]
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rdx
; AVX512BW-NEXT: vpextrq $1, %xmm1, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vmovq %xmm5, %rdx
; AVX512BW-NEXT: vmovq %xmm1, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm4[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm9, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm8
; AVX512BW-NEXT: vextracti32x4 $3, %zmm6, %xmm1
; AVX512BW-NEXT: vpextrq $1, %xmm1, %rdx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm2, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vmovq %xmm1, %rdx
; AVX512BW-NEXT: vmovq %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm1
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm5[0]
; AVX512BW-NEXT: vextracti32x4 $2, %zmm6, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rdx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm2, %xmm5
; AVX512BW-NEXT: vpextrq $1, %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vmovq %xmm4, %rdx
; AVX512BW-NEXT: vmovq %xmm5, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm4[0],xmm0[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm1
; AVX512BW-NEXT: vextracti32x4 $1, %zmm6, %xmm0
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm2, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vmovq %xmm0, %rdx
; AVX512BW-NEXT: vmovq %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm5[0]
; AVX512BW-NEXT: vpextrq $1, %xmm6, %rdx
; AVX512BW-NEXT: vpextrq $1, %xmm2, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vmovq %xmm6, %rdx
; AVX512BW-NEXT: vmovq %xmm2, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm4[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm0, %ymm2, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm1, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm1
; AVX512BW-NEXT: vextracti32x4 $3, %zmm7, %xmm0
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512BW-NEXT: vextracti32x4 $3, %zmm3, %xmm2
; AVX512BW-NEXT: vpextrq $1, %xmm2, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vmovq %xmm0, %rdx
; AVX512BW-NEXT: vmovq %xmm2, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; AVX512BW-NEXT: vextracti32x4 $2, %zmm7, %xmm2
; AVX512BW-NEXT: vpextrq $1, %xmm2, %rdx
; AVX512BW-NEXT: vextracti32x4 $2, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vmovq %xmm2, %rdx
; AVX512BW-NEXT: vmovq %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm2
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm5[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm0, %ymm2, %ymm2
; AVX512BW-NEXT: vextracti32x4 $1, %zmm7, %xmm0
; AVX512BW-NEXT: vpextrq $1, %xmm0, %rdx
; AVX512BW-NEXT: vextracti32x4 $1, %zmm3, %xmm4
; AVX512BW-NEXT: vpextrq $1, %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm5
; AVX512BW-NEXT: vmovq %xmm0, %rdx
; AVX512BW-NEXT: vmovq %xmm4, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm0
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm5[0]
; AVX512BW-NEXT: vpextrq $1, %xmm7, %rdx
; AVX512BW-NEXT: vpextrq $1, %xmm3, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: movl $0, %edx
; AVX512BW-NEXT: cmovgq %rcx, %rdx
; AVX512BW-NEXT: vmovq %rdx, %xmm4
; AVX512BW-NEXT: vmovq %xmm7, %rdx
; AVX512BW-NEXT: vmovq %xmm3, %rsi
; AVX512BW-NEXT: cmpq %rdx, %rsi
; AVX512BW-NEXT: cmovgq %rcx, %rax
; AVX512BW-NEXT: vmovq %rax, %xmm3
; AVX512BW-NEXT: vpunpcklqdq {{.*#+}} xmm3 = xmm3[0],xmm4[0]
; AVX512BW-NEXT: vinserti128 $1, %xmm0, %ymm3, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm2, %zmm0, %zmm0
; AVX512BW-NEXT: vpmovqd %zmm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512BW-NEXT: vpmovdw %zmm0, %ymm0
; AVX512BW-NEXT: vinserti64x4 $1, %ymm0, %zmm8, %zmm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
; AVX512BW-NEXT: retq
[X86][SSE] Added 2048-bit vector comparison tests Upper limit of what can be held in a <32 x i8> result llvm-svn: 276666
2016-07-26 01:56:01 +08:00
%1 = icmp sgt <32 x i64> %a0, %a1
ret <32 x i1> %1
}