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

7648 lines
264 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: cmpltpd %xmm0, %xmm1
; SSE-NEXT: movapd %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v2f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX: # %bb.0:
[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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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 %xmm0, %xmm1
; SSE-NEXT: movaps %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v4f32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX: # %bb.0:
[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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[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 %xmm1, %xmm0
; SSE42-NEXT: retq
;
; AVX-LABEL: test_cmp_v2i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX: # %bb.0:
[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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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 %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v4i32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX: # %bb.0:
[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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: pcmpgtw %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v8i16:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX: # %bb.0:
[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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: pcmpgtb %xmm1, %xmm0
; SSE-NEXT: retq
;
; AVX-LABEL: test_cmp_v16i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX: # %bb.0:
[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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: cmpltpd %xmm1, %xmm3
; SSE-NEXT: cmpltpd %xmm0, %xmm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %ymm1, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512: # %bb.0:
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: vcmpltpd %ymm0, %ymm1, %ymm0
; AVX512-NEXT: vpmovqd %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: cmpltps %xmm1, %xmm3
; SSE-NEXT: cmpltps %xmm0, %xmm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %ymm1, %ymm0
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512: # %bb.0:
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: vcmpltps %ymm0, %ymm1, %ymm0
; AVX512-NEXT: vpmovdw %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[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 %xmm3, %xmm1
; SSE42-NEXT: pcmpgtq %xmm2, %xmm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpcmpgtq %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vpcmpgtq %xmm1, %xmm0, %xmm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512: # %bb.0:
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: vpcmpgtq %ymm1, %ymm0, %ymm0
; AVX512-NEXT: vpmovqd %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: pcmpgtd %xmm3, %xmm1
; SSE-NEXT: pcmpgtd %xmm2, %xmm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %xmm1, %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpcmpgtd %xmm2, %xmm3, %xmm2
; AVX1-NEXT: vpcmpgtd %xmm1, %xmm0, %xmm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512: # %bb.0:
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; AVX512-NEXT: vpcmpgtd %ymm1, %ymm0, %ymm0
; AVX512-NEXT: vpmovdw %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[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: vpcmpgtw %ymm1, %ymm0, %ymm0
; AVX512BW-NEXT: vpmovwb %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[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: pcmpgtb %xmm2, %xmm0
; SSE2-NEXT: pcmpgtb %xmm3, %xmm1
; SSE2-NEXT: movdqa %xmm1, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[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: pcmpgtb %xmm2, %xmm0
; SSE42-NEXT: pcmpgtb %xmm3, %xmm1
; SSE42-NEXT: pextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm1, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm1, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm0, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm0, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512: # %bb.0:
[X86][AVX512] Added AVX512 comparison tests llvm-svn: 265247
2016-04-03 05:24:42 +08:00
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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: cmpltpd %xmm3, %xmm7
; SSE-NEXT: cmpltpd %xmm2, %xmm6
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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
; SSE-NEXT: cmpltpd %xmm1, %xmm5
; SSE-NEXT: cmpltpd %xmm0, %xmm4
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %xmm5, %xmm4
; SSE-NEXT: packssdw %xmm6, %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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 %ymm1, %ymm3, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: vcmpltpd %zmm0, %zmm1, %k1
[X86] Use vector widening to support sign extend from i1 when the dest type is not 512-bits and vlx is not enabled. Previously we used a wider element type and truncated. But its more efficient to keep the element type and drop unused elements. If BWI isn't supported and we have a i16 or i8 type, we'll extend it to be i32 and still use a truncate. llvm-svn: 319740
2017-12-05 14:37:21 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
; AVX512F-NEXT: vpmovdw %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512F-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: vcmpltpd %zmm0, %zmm1, %k0
[X86] Use vector widening to support sign extend from i1 when the dest type is not 512-bits and vlx is not enabled. Previously we used a wider element type and truncated. But its more efficient to keep the element type and drop unused elements. If BWI isn't supported and we have a i16 or i8 type, we'll extend it to be i32 and still use a truncate. llvm-svn: 319740
2017-12-05 14:37:21 +08:00
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm0
; AVX512DQ-NEXT: vpmovdw %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512DQ-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86][TD][vpmovm2 ] New TD pattern for the vpmovm2 instruction Up until now, vpmovm2 instruction described its destination operand size by the source operand size. This patch adds new pattern for the vpmovm2 instruction. The node describes new expansion of the destination (from {128|256} to 512). Differential Revision: https://reviews.llvm.org/D30654 llvm-svn: 298586
2017-03-23 17:57:01 +08:00
; AVX512BW-NEXT: vcmpltpd %zmm0, %zmm1, %k0
; AVX512BW-NEXT: vpmovm2w %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $zmm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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 %xmm3, %xmm7
; SSE-NEXT: cmpltps %xmm2, %xmm6
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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 %ymm1, %ymm3, %ymm1
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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 %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: vcmpltps %ymm1, %ymm3, %ymm1
; AVX2-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
[X86][SSE] truncateVectorWithPACK - Use src type instead of dst to select between PACK*SDW/PACK*SWB Try to keep PACK*SDW/PACK*SWB as wide as possible, this helps ComputeNumSignBits as it can only peek through bitcasts to wider types, pre-AVX2 codegen was already doing this as it could peek through bitcasts/subvectors more easily than AVX2 could through shuffles. This shouldn't affect existing results as calls to truncateVectorWithPACK ensure we have enough sign bits to pack to the same value, but it should make it possible to use truncateVectorWithPACK chains to perform saturation in combineTruncateWithSat with a future patch. llvm-svn: 325149
2018-02-15 02:23:58 +08:00
; AVX2-NEXT: vpackssdw %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86][TD][vpmovm2 ] New TD pattern for the vpmovm2 instruction Up until now, vpmovm2 instruction described its destination operand size by the source operand size. This patch adds new pattern for the vpmovm2 instruction. The node describes new expansion of the destination (from {128|256} to 512). Differential Revision: https://reviews.llvm.org/D30654 llvm-svn: 298586
2017-03-23 17:57:01 +08:00
; AVX512BW-NEXT: vcmpltps %zmm0, %zmm1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $zmm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %xmm7, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %xmm3, %xmm0
; SSE2-NEXT: packssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[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 %xmm7, %xmm3
; SSE42-NEXT: pcmpgtq %xmm6, %xmm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %xmm1, %xmm0
; SSE42-NEXT: packssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %ymm3, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtq %xmm4, %xmm5, %xmm4
; AVX1-NEXT: vpcmpgtq %xmm3, %xmm1, %xmm1
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: vpcmpgtq %zmm1, %zmm0, %k1
[X86] Use vector widening to support sign extend from i1 when the dest type is not 512-bits and vlx is not enabled. Previously we used a wider element type and truncated. But its more efficient to keep the element type and drop unused elements. If BWI isn't supported and we have a i16 or i8 type, we'll extend it to be i32 and still use a truncate. llvm-svn: 319740
2017-12-05 14:37:21 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
; AVX512F-NEXT: vpmovdw %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512F-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: vpcmpgtq %zmm1, %zmm0, %k0
[X86] Use vector widening to support sign extend from i1 when the dest type is not 512-bits and vlx is not enabled. Previously we used a wider element type and truncated. But its more efficient to keep the element type and drop unused elements. If BWI isn't supported and we have a i16 or i8 type, we'll extend it to be i32 and still use a truncate. llvm-svn: 319740
2017-12-05 14:37:21 +08:00
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm0
; AVX512DQ-NEXT: vpmovdw %zmm0, %ymm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512DQ-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86][TD][vpmovm2 ] New TD pattern for the vpmovm2 instruction Up until now, vpmovm2 instruction described its destination operand size by the source operand size. This patch adds new pattern for the vpmovm2 instruction. The node describes new expansion of the destination (from {128|256} to 512). Differential Revision: https://reviews.llvm.org/D30654 llvm-svn: 298586
2017-03-23 17:57:01 +08:00
; AVX512BW-NEXT: vpcmpgtq %zmm1, %zmm0, %k0
; AVX512BW-NEXT: vpmovm2w %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $zmm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.0:
[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 %xmm7, %xmm3
; SSE-NEXT: pcmpgtd %xmm6, %xmm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %xmm1, %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 %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %ymm3, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtd %xmm4, %xmm5, %xmm4
; AVX1-NEXT: vpcmpgtd %xmm3, %xmm1, %xmm1
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %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 %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: vpcmpgtd %ymm3, %ymm1, %ymm1
; AVX2-NEXT: vpcmpgtd %ymm2, %ymm0, %ymm0
[X86][SSE] truncateVectorWithPACK - Use src type instead of dst to select between PACK*SDW/PACK*SWB Try to keep PACK*SDW/PACK*SWB as wide as possible, this helps ComputeNumSignBits as it can only peek through bitcasts to wider types, pre-AVX2 codegen was already doing this as it could peek through bitcasts/subvectors more easily than AVX2 could through shuffles. This shouldn't affect existing results as calls to truncateVectorWithPACK ensure we have enough sign bits to pack to the same value, but it should make it possible to use truncateVectorWithPACK chains to perform saturation in combineTruncateWithSat with a future patch. llvm-svn: 325149
2018-02-15 02:23:58 +08:00
; AVX2-NEXT: vpackssdw %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86][TD][vpmovm2 ] New TD pattern for the vpmovm2 instruction Up until now, vpmovm2 instruction described its destination operand size by the source operand size. This patch adds new pattern for the vpmovm2 instruction. The node describes new expansion of the destination (from {128|256} to 512). Differential Revision: https://reviews.llvm.org/D30654 llvm-svn: 298586
2017-03-23 17:57:01 +08:00
; AVX512BW-NEXT: vpcmpgtd %zmm1, %zmm0, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $zmm0
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[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: pcmpgtw %xmm5, %xmm1
; SSE2-NEXT: pcmpgtw %xmm4, %xmm0
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE2-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
; SSE2-NEXT: pcmpgtw %xmm7, %xmm3
; SSE2-NEXT: pcmpgtw %xmm6, %xmm2
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE2-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
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i16:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; 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: pcmpgtw %xmm5, %xmm1
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; 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 %xmm7, %xmm3
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +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: pextrb $2, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $4, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $6, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $8, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $10, %xmm2, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $12, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $14, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $2, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $4, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $6, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $10, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $14, %xmm3, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $4, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $6, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $8, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $10, %xmm0, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $12, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $14, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $2, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $4, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $6, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $10, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $14, %xmm1, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i16:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[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, %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86][TD][vpmovm2 ] New TD pattern for the vpmovm2 instruction Up until now, vpmovm2 instruction described its destination operand size by the source operand size. This patch adds new pattern for the vpmovm2 instruction. The node describes new expansion of the destination (from {128|256} to 512). Differential Revision: https://reviews.llvm.org/D30654 llvm-svn: 298586
2017-03-23 17:57:01 +08:00
; AVX512BW-NEXT: vpcmpgtw %zmm1, %zmm0, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $ymm0 killed $ymm0 killed $zmm0
[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 <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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[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: 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)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 6(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 4(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm1, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v64i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[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: pcmpgtb %xmm4, %xmm0
; SSE42-NEXT: pcmpgtb %xmm5, %xmm1
; SSE42-NEXT: pcmpgtb %xmm6, %xmm2
; SSE42-NEXT: pcmpgtb %xmm7, %xmm3
; SSE42-NEXT: pextrb $1, %xmm3, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm3, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm3, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm2, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm2, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm1, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm1, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm0, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm0, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v64i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm5
; AVX1-NEXT: vpcmpgtb %xmm4, %xmm5, %xmm4
[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: vpcmpgtb %xmm2, %xmm0, %xmm0
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm5
; AVX1-NEXT: vpcmpgtb %xmm2, %xmm5, %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
; AVX1-NEXT: vpcmpgtb %xmm3, %xmm1, %xmm1
; AVX1-NEXT: vpextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: vpextrb $0, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $2, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $3, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $4, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $5, %xmm1, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $6, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $7, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $1, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $2, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $3, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $5, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $6, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $7, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm2, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, 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
; AVX1-NEXT: vpextrb $1, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: vpextrb $0, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $2, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $3, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $4, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $5, %xmm0, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $6, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $7, %xmm0, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm0, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm0, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm0, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm0, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $1, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $2, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $3, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $5, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $6, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $7, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm4, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, (%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
; AVX1-NEXT: movq %rdi, %rax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v64i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[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: vpcmpgtb %ymm2, %ymm0, %ymm0
; AVX2-NEXT: vpcmpgtb %ymm3, %ymm1, %ymm1
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: vpextrb $0, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $2, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $3, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $4, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
[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: vpextrb $5, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $6, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $7, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vextracti128 $1, %ymm1, %xmm1
; AVX2-NEXT: vpextrb $0, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $1, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $2, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $3, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $5, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $6, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $7, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm1, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, 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
; AVX2-NEXT: vpextrb $1, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: vpextrb $0, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $2, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $3, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $4, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
; AVX2-NEXT: vpextrb $5, %xmm0, %eax
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $6, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $7, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX2-NEXT: vpextrb $0, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $1, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $2, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $3, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $5, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $6, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $7, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm0, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, (%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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: vpcmpgtb %ymm2, %ymm0, %ymm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm4
; AVX512F-NEXT: vpcmpgtb %ymm3, %ymm1, %ymm2
; AVX512F-NEXT: vextracti128 $1, %ymm2, %xmm3
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512F-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vmovdqa %xmm4, %xmm1
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512F-NEXT: # kill: def $xmm2 killed $xmm2 killed $ymm2
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: vpcmpgtb %ymm2, %ymm0, %ymm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm4
; AVX512DQ-NEXT: vpcmpgtb %ymm3, %ymm1, %ymm2
; AVX512DQ-NEXT: vextracti128 $1, %ymm2, %xmm3
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512DQ-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vmovdqa %xmm4, %xmm1
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512DQ-NEXT: # kill: def $xmm2 killed $xmm2 killed $ymm2
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE: # %bb.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
; 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %xmm13, %xmm9
; SSE-NEXT: packssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE-NEXT: packssdw %xmm11, %xmm0
; SSE-NEXT: packssdw %xmm10, %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 %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm6, %xmm2, %xmm2
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpackssdw %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] Added 1024-bit vector comparison tests More examples of PR22603, poor 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm3, %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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] truncateVectorWithPACK - Use src type instead of dst to select between PACK*SDW/PACK*SWB Try to keep PACK*SDW/PACK*SWB as wide as possible, this helps ComputeNumSignBits as it can only peek through bitcasts to wider types, pre-AVX2 codegen was already doing this as it could peek through bitcasts/subvectors more easily than AVX2 could through shuffles. This shouldn't affect existing results as calls to truncateVectorWithPACK ensure we have enough sign bits to pack to the same value, but it should make it possible to use truncateVectorWithPACK chains to perform saturation in combineTruncateWithSat with a future patch. llvm-svn: 325149
2018-02-15 02:23:58 +08:00
; AVX2-NEXT: vpackssdw %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: 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] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512F-LABEL: test_cmp_v16f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512F-NEXT: vcmpltpd %zmm0, %zmm2, %k0
; AVX512F-NEXT: vcmpltpd %zmm1, %zmm3, %k1
; AVX512F-NEXT: kunpckbw %k0, %k1, %k1
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vzeroupper
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512DQ-NEXT: vcmpltpd %zmm0, %zmm2, %k0
; AVX512DQ-NEXT: vcmpltpd %zmm1, %zmm3, %k1
; AVX512DQ-NEXT: kunpckbw %k0, %k1, %k0
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vzeroupper
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512BW-NEXT: vcmpltpd %zmm0, %zmm2, %k0
; AVX512BW-NEXT: vcmpltpd %zmm1, %zmm3, %k1
; AVX512BW-NEXT: kunpckbw %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $zmm0
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512BW-NEXT: vzeroupper
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.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
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm9
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm11
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-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
; SSE2-NEXT: movaps {{[0-9]+}}(%rsp), %xmm12
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-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
; 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
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movaps {{.*#+}} xmm3 = [255,255,255,255]
; SSE2-NEXT: andps %xmm3, %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
; SSE2-NEXT: cmpltps %xmm2, %xmm14
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm14
; SSE2-NEXT: packuswb %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
; SSE2-NEXT: cmpltps %xmm1, %xmm13
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm13
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: cmpltps %xmm0, %xmm8
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm8
; SSE2-NEXT: packuswb %xmm13, %xmm8
; SSE2-NEXT: packuswb %xmm14, %xmm8
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: cmpltps %xmm7, %xmm12
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm12
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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: cmpltps %xmm6, %xmm10
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm10
; SSE2-NEXT: packuswb %xmm12, %xmm10
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: cmpltps %xmm5, %xmm11
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm11
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: cmpltps %xmm4, %xmm9
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andps %xmm3, %xmm9
; SSE2-NEXT: packuswb %xmm11, %xmm9
; SSE2-NEXT: packuswb %xmm10, %xmm9
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: movdqa %xmm9, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: movdqa %xmm8, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32f32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm15
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm14
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm13
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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), %xmm12
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE42-NEXT: movaps {{[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: movaps {{[0-9]+}}(%rsp), %xmm10
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm9
; SSE42-NEXT: movaps {{[0-9]+}}(%rsp), %xmm8
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: cmpltps %xmm3, %xmm8
; SSE42-NEXT: cmpltps %xmm2, %xmm9
; SSE42-NEXT: cmpltps %xmm1, %xmm10
; SSE42-NEXT: cmpltps %xmm0, %xmm11
; SSE42-NEXT: cmpltps %xmm7, %xmm12
; SSE42-NEXT: cmpltps %xmm6, %xmm13
; SSE42-NEXT: cmpltps %xmm5, %xmm14
; SSE42-NEXT: cmpltps %xmm4, %xmm15
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE42-NEXT: pextrb $4, %xmm15, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm15, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $8, %xmm15, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $12, %xmm15, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $0, %xmm14, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE42-NEXT: pextrb $4, %xmm14, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $8, %xmm14, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $12, %xmm14, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm13, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm13, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm13, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm13, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm12, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm12, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm12, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm12, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 2(%rdi)
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE42-NEXT: pextrb $4, %xmm11, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm11, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $8, %xmm11, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $12, %xmm11, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $0, %xmm10, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE42-NEXT: pextrb $4, %xmm10, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $8, %xmm10, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $12, %xmm10, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm9, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm9, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm9, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm9, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm8, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm8, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm8, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm8, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32f32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %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 %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.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
; AVX2-NEXT: vcmpltps %ymm3, %ymm7, %ymm3
; AVX2-NEXT: vcmpltps %ymm2, %ymm6, %ymm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm3, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vcmpltps %zmm1, %zmm3, %k1
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vcmpltps %zmm0, %zmm2, %k2
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k2} {z}
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm1, %zmm1, %zmm1 {%k1} {z}
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
[DAGCombiner] Don't combine aext(setcc) if the setcc is already using the target's preferred result type. With AVX512 vXi1 types are legal so we shouldn't be extending them. This change is similar to existing code in the zext(setcc) combine. llvm-svn: 319120
2017-11-28 07:51:40 +08:00
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[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_v32f32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: vcmpltps %zmm1, %zmm3, %k0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vcmpltps %zmm0, %zmm2, %k1
; AVX512DQ-NEXT: vpmovm2d %k1, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm1
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
[DAGCombiner] Don't combine aext(setcc) if the setcc is already using the target's preferred result type. With AVX512 vXi1 types are legal so we shouldn't be extending them. This change is similar to existing code in the zext(setcc) combine. llvm-svn: 319120
2017-11-28 07:51:40 +08:00
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[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_v32f32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512BW-NEXT: vcmpltps %zmm0, %zmm2, %k0
; AVX512BW-NEXT: vcmpltps %zmm1, %zmm3, %k1
; AVX512BW-NEXT: kunpckwd %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $ymm0 killed $ymm0 killed $zmm0
[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
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.0:
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; 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
; 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 {{.*#+}} xmm7 = xmm7[1,1,3,3]
; SSE2-NEXT: pand %xmm11, %xmm7
; SSE2-NEXT: pshufd {{.*#+}} xmm10 = xmm10[1,1,3,3]
; SSE2-NEXT: por %xmm7, %xmm10
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %xmm9, %xmm10
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %xmm6, %xmm4
; SSE2-NEXT: packssdw %xmm10, %xmm4
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %xmm5, %xmm2
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE2-NEXT: packssdw %xmm3, %xmm0
; SSE2-NEXT: packssdw %xmm2, %xmm0
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; SSE2-NEXT: packsswb %xmm4, %xmm0
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v16i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm6
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %xmm7, %xmm6
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm4
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %xmm5, %xmm4
; SSE42-NEXT: packssdw %xmm6, %xmm4
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %xmm3, %xmm2
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm1
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; SSE42-NEXT: packssdw %xmm1, %xmm0
; SSE42-NEXT: packssdw %xmm2, %xmm0
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; SSE42-NEXT: packsswb %xmm4, %xmm0
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v16i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm9
; AVX1-NEXT: vpcmpgtq %xmm8, %xmm9, %xmm8
; AVX1-NEXT: vpcmpgtq %xmm7, %xmm3, %xmm3
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm8, %xmm3, %xmm8
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpackssdw %xmm8, %xmm2, %xmm2
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm1, %xmm1
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpackssdw %xmm1, %xmm0, %xmm0
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; AVX1-NEXT: vpacksswb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v16i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; AVX2-NEXT: vpcmpgtq %ymm7, %ymm3, %ymm3
; AVX2-NEXT: vpcmpgtq %ymm6, %ymm2, %ymm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm3, %ymm2, %ymm2
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; AVX2-NEXT: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
; AVX2-NEXT: vpcmpgtq %ymm5, %ymm1, %ymm1
; AVX2-NEXT: vpcmpgtq %ymm4, %ymm0, %ymm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm1, %ymm0, %ymm0
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86][SSE] truncateVectorWithPACK - Use src type instead of dst to select between PACK*SDW/PACK*SWB Try to keep PACK*SDW/PACK*SWB as wide as possible, this helps ComputeNumSignBits as it can only peek through bitcasts to wider types, pre-AVX2 codegen was already doing this as it could peek through bitcasts/subvectors more easily than AVX2 could through shuffles. This shouldn't affect existing results as calls to truncateVectorWithPACK ensure we have enough sign bits to pack to the same value, but it should make it possible to use truncateVectorWithPACK chains to perform saturation in combineTruncateWithSat with a future patch. llvm-svn: 325149
2018-02-15 02:23:58 +08:00
; AVX2-NEXT: vpackssdw %ymm2, %ymm0, %ymm0
[AVX512] Don't switch unmasked subvector insert/extract instructions when AVX512DQI is enabled. There's no reason to switch instructions with and without DQI. It just creates extra isel patterns and test divergences. There is however value in enabling the masked version of the instructions with DQI. This required introducing some new multiclasses to enabling this splitting. Differential Revision: https://reviews.llvm.org/D36661 llvm-svn: 311091
2017-08-17 23:40:25 +08:00
; AVX2-NEXT: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpacksswb %xmm1, %xmm0, %xmm0
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled. Similar for vXi16/vXi8 with BWI. Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization. llvm-svn: 319059
2017-11-28 01:51:55 +08:00
; AVX512F-LABEL: test_cmp_v16i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled. Similar for vXi16/vXi8 with BWI. Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization. llvm-svn: 319059
2017-11-28 01:51:55 +08:00
; AVX512F-NEXT: vpcmpgtq %zmm2, %zmm0, %k0
; AVX512F-NEXT: vpcmpgtq %zmm3, %zmm1, %k1
; AVX512F-NEXT: kunpckbw %k0, %k1, %k1
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k1} {z}
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vzeroupper
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v16i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled. Similar for vXi16/vXi8 with BWI. Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization. llvm-svn: 319059
2017-11-28 01:51:55 +08:00
; AVX512DQ-NEXT: vpcmpgtq %zmm2, %zmm0, %k0
; AVX512DQ-NEXT: vpcmpgtq %zmm3, %zmm1, %k1
; AVX512DQ-NEXT: kunpckbw %k0, %k1, %k0
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vzeroupper
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v16i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled. Similar for vXi16/vXi8 with BWI. Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization. llvm-svn: 319059
2017-11-28 01:51:55 +08:00
; AVX512BW-NEXT: vpcmpgtq %zmm2, %zmm0, %k0
; AVX512BW-NEXT: vpcmpgtq %zmm3, %zmm1, %k1
; AVX512BW-NEXT: kunpckbw %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $xmm0 killed $xmm0 killed $zmm0
[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled. Similar for vXi16/vXi8 with BWI. Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization. llvm-svn: 319059
2017-11-28 01:51:55 +08:00
; AVX512BW-NEXT: vzeroupper
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.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
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm3
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa {{.*#+}} xmm8 = [255,255,255,255]
; SSE2-NEXT: pand %xmm8, %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
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm2
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %xmm2
; SSE2-NEXT: packuswb %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
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %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
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm0
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %xmm0
; SSE2-NEXT: packuswb %xmm1, %xmm0
; SSE2-NEXT: packuswb %xmm2, %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: pcmpgtd {{[0-9]+}}(%rsp), %xmm7
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %xmm7
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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: pcmpgtd {{[0-9]+}}(%rsp), %xmm6
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %xmm6
; SSE2-NEXT: packuswb %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
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm5
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %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
; SSE2-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm4
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm8, %xmm4
; SSE2-NEXT: packuswb %xmm5, %xmm4
; SSE2-NEXT: packuswb %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
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[X86][SSE] Add support for lowering v8i16 binary shuffles to PACKSS/PACKUS Missed in D38472 llvm-svn: 314916
2017-10-05 01:31:28 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm3
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm1
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm0
[X86][SSE] Add support for lowering v8i16 binary shuffles to PACKSS/PACKUS Missed in D38472 llvm-svn: 314916
2017-10-05 01:31:28 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm7
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pcmpgtd {{[0-9]+}}(%rsp), %xmm4
[X86][SSE] Add support for lowering v8i16 binary shuffles to PACKSS/PACKUS Missed in D38472 llvm-svn: 314916
2017-10-05 01:31:28 +08:00
; SSE42-NEXT: pextrb $4, %xmm4, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $8, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $12, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $0, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $4, %xmm5, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $8, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $12, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm7, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 2(%rdi)
[X86][SSE] Add support for lowering v8i16 binary shuffles to PACKSS/PACKUS Missed in D38472 llvm-svn: 314916
2017-10-05 01:31:28 +08:00
; SSE42-NEXT: pextrb $4, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $8, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $12, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $4, %xmm1, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $12, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $4, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $12, %xmm3, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v32i32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.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
; 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %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 %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %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 %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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.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
; AVX2-NEXT: vpcmpgtd %ymm7, %ymm3, %ymm3
; AVX2-NEXT: vpcmpgtd %ymm6, %ymm2, %ymm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm3, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vpcmpgtd %zmm3, %zmm1, %k1
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vpcmpgtd %zmm2, %zmm0, %k2
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k2} {z}
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm1, %zmm1, %zmm1 {%k1} {z}
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
[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: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512F-NEXT: retq
;
; AVX512DQ-LABEL: test_cmp_v32i32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: vpcmpgtd %zmm3, %zmm1, %k0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vpcmpgtd %zmm2, %zmm0, %k1
; AVX512DQ-NEXT: vpmovm2d %k1, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm1
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
[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: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX512DQ-NEXT: retq
;
; AVX512BW-LABEL: test_cmp_v32i32:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512BW-NEXT: vpcmpgtd %zmm2, %zmm0, %k0
; AVX512BW-NEXT: vpcmpgtd %zmm3, %zmm1, %k1
; AVX512BW-NEXT: kunpckwd %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $ymm0 killed $ymm0 killed $zmm0
[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 <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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.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
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm0
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE2-NEXT: packsswb %xmm1, %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: pcmpgtw {{[0-9]+}}(%rsp), %xmm3
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm2
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE2-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
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm4
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE2-NEXT: packsswb %xmm5, %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: pcmpgtw {{[0-9]+}}(%rsp), %xmm7
; SSE2-NEXT: pcmpgtw {{[0-9]+}}(%rsp), %xmm6
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE2-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
; SSE2-NEXT: movdqa %xmm6, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 6(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 4(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v64i16:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; 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: pcmpgtw {{[0-9]+}}(%rsp), %xmm1
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; 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), %xmm3
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +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), %xmm5
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +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), %xmm7
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +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: pextrb $2, %xmm6, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $4, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $6, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $8, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $10, %xmm6, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $12, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $14, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $2, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $4, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $6, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $10, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $14, %xmm7, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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, %xmm4, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $4, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $6, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $8, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $10, %xmm4, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $12, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $14, %xmm4, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $2, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $4, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $6, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $10, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $14, %xmm5, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $4, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $6, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $8, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $10, %xmm2, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $12, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $14, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $2, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $4, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $6, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $10, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $14, %xmm3, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $4, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $6, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $8, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $10, %xmm0, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $12, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $14, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $2, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $4, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $6, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $10, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $14, %xmm1, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v64i16:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm9
; AVX1-NEXT: vpcmpgtw %xmm8, %xmm9, %xmm8
; AVX1-NEXT: vpcmpgtw %xmm5, %xmm1, %xmm9
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm5
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX1-NEXT: vpcmpgtw %xmm5, %xmm1, %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
; AVX1-NEXT: vpcmpgtw %xmm4, %xmm0, %xmm0
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm4
; AVX1-NEXT: vpcmpgtw %xmm1, %xmm4, %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
; AVX1-NEXT: vpcmpgtw %xmm7, %xmm3, %xmm3
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm7
; AVX1-NEXT: vpcmpgtw %xmm1, %xmm7, %xmm7
; AVX1-NEXT: vpcmpgtw %xmm6, %xmm2, %xmm2
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX1-NEXT: vpextrb $2, %xmm2, %eax
; AVX1-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vpextrb $0, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $4, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $6, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $8, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $10, %xmm2, %eax
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX1-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $12, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $14, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm7, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $2, %xmm7, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm7, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $6, %xmm7, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm7, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $10, %xmm7, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm7, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $14, %xmm7, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $2, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $6, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $10, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $14, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $2, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $6, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $10, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $14, %xmm4, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, 4(%rdi)
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX1-NEXT: vpextrb $2, %xmm0, %eax
; AVX1-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vpextrb $0, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $4, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $6, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $8, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $10, %xmm0, %eax
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX1-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $12, %xmm0, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $14, %xmm0, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $2, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $6, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $10, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $14, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $2, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $6, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $10, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $14, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $2, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $6, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $10, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $14, %xmm8, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, (%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
; AVX1-NEXT: movq %rdi, %rax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v64i16:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.0:
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: vpcmpgtw %ymm5, %ymm1, %ymm5
; AVX2-NEXT: vextracti128 $1, %ymm5, %xmm1
; AVX2-NEXT: vpcmpgtw %ymm4, %ymm0, %ymm4
; AVX2-NEXT: vextracti128 $1, %ymm4, %xmm0
; AVX2-NEXT: vpcmpgtw %ymm7, %ymm3, %ymm7
; AVX2-NEXT: vextracti128 $1, %ymm7, %xmm3
; AVX2-NEXT: vpcmpgtw %ymm6, %ymm2, %ymm6
; AVX2-NEXT: vextracti128 $1, %ymm6, %xmm2
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX2-NEXT: vpextrb $2, %xmm6, %eax
; AVX2-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: vpextrb $0, %xmm6, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $4, %xmm6, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $6, %xmm6, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $8, %xmm6, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
; AVX2-NEXT: vpextrb $10, %xmm6, %eax
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX2-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $12, %xmm6, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $14, %xmm6, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $0, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $2, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $6, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $10, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $14, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $0, %xmm7, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $2, %xmm7, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm7, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $6, %xmm7, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm7, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $10, %xmm7, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm7, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $14, %xmm7, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $0, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $2, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $6, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $10, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $14, %xmm3, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, 4(%rdi)
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX2-NEXT: vpextrb $2, %xmm4, %eax
; AVX2-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: vpextrb $0, %xmm4, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $4, %xmm4, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $6, %xmm4, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $8, %xmm4, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
; AVX2-NEXT: vpextrb $10, %xmm4, %eax
[X86][SSE] Add support for PACKSS nodes to faux shuffle extraction If the inputs won't saturate during packing then we can treat the PACKSS as a truncation shuffle llvm-svn: 305091
2017-06-10 01:29:52 +08:00
; AVX2-NEXT: andl $1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $12, %xmm4, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $14, %xmm4, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $0, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $2, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $6, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $10, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $14, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $0, %xmm5, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $2, %xmm5, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm5, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $6, %xmm5, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm5, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $10, %xmm5, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm5, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $14, %xmm5, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $0, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $2, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $6, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $10, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $14, %xmm1, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, (%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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[SelectionDAG][X86] Improve legalization of v32i1 CONCAT_VECTORS of v16i1 for AVX512F. A v32i1 CONCAT_VECTORS of v16i1 uses promotion to v32i8 to legalize the v32i1. This results in a bunch of extract_vector_elts and a build_vector that ultimately gets scalarized. This patch checks to see if v16i8 is legal and inserts a any_extend to that so that we can concat v16i8 to v32i8 and avoid creating the extracts. llvm-svn: 320674
2017-12-14 16:25:58 +08:00
; AVX512F-NEXT: vpcmpgtw %ymm7, %ymm3, %ymm3
[X86] Add DAG combine to promote vXi1 result of a vXi8/vXi16 setcc when we have AVX512 but not BWI. This avoids having the result type stick around until lowering where we have to extend the setcc and insert a truncate. If we get the types converted early we can do more to optimize it. llvm-svn: 322432
2018-01-13 14:24:46 +08:00
; AVX512F-NEXT: vpcmpgtw %ymm6, %ymm2, %ymm2
; AVX512F-NEXT: vpcmpgtw %ymm5, %ymm1, %ymm1
[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: vpcmpgtw %ymm4, %ymm0, %ymm0
; AVX512F-NEXT: vpmovsxwd %ymm0, %zmm0
[SelectionDAG][X86] Improve legalization of v32i1 CONCAT_VECTORS of v16i1 for AVX512F. A v32i1 CONCAT_VECTORS of v16i1 uses promotion to v32i8 to legalize the v32i1. This results in a bunch of extract_vector_elts and a build_vector that ultimately gets scalarized. This patch checks to see if v16i8 is legal and inserts a any_extend to that so that we can concat v16i8 to v32i8 and avoid creating the extracts. llvm-svn: 320674
2017-12-14 16:25:58 +08:00
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
; AVX512F-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
[X86] Add DAG combine to promote vXi1 result of a vXi8/vXi16 setcc when we have AVX512 but not BWI. This avoids having the result type stick around until lowering where we have to extend the setcc and insert a truncate. If we get the types converted early we can do more to optimize it. llvm-svn: 322432
2018-01-13 14:24:46 +08:00
; AVX512F-NEXT: vpmovsxwd %ymm2, %zmm2
; AVX512F-NEXT: vpmovdb %zmm2, %xmm2
; AVX512F-NEXT: vpmovsxwd %ymm3, %zmm3
; AVX512F-NEXT: vpmovdb %zmm3, %xmm3
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[SelectionDAG][X86] Improve legalization of v32i1 CONCAT_VECTORS of v16i1 for AVX512F. A v32i1 CONCAT_VECTORS of v16i1 uses promotion to v32i8 to legalize the v32i1. This results in a bunch of extract_vector_elts and a build_vector that ultimately gets scalarized. This patch checks to see if v16i8 is legal and inserts a any_extend to that so that we can concat v16i8 to v32i8 and avoid creating the extracts. llvm-svn: 320674
2017-12-14 16:25:58 +08:00
; AVX512DQ-NEXT: vpcmpgtw %ymm7, %ymm3, %ymm3
[X86] Add DAG combine to promote vXi1 result of a vXi8/vXi16 setcc when we have AVX512 but not BWI. This avoids having the result type stick around until lowering where we have to extend the setcc and insert a truncate. If we get the types converted early we can do more to optimize it. llvm-svn: 322432
2018-01-13 14:24:46 +08:00
; AVX512DQ-NEXT: vpcmpgtw %ymm6, %ymm2, %ymm2
; AVX512DQ-NEXT: vpcmpgtw %ymm5, %ymm1, %ymm1
[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: vpcmpgtw %ymm4, %ymm0, %ymm0
; AVX512DQ-NEXT: vpmovsxwd %ymm0, %zmm0
[SelectionDAG][X86] Improve legalization of v32i1 CONCAT_VECTORS of v16i1 for AVX512F. A v32i1 CONCAT_VECTORS of v16i1 uses promotion to v32i8 to legalize the v32i1. This results in a bunch of extract_vector_elts and a build_vector that ultimately gets scalarized. This patch checks to see if v16i8 is legal and inserts a any_extend to that so that we can concat v16i8 to v32i8 and avoid creating the extracts. llvm-svn: 320674
2017-12-14 16:25:58 +08:00
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
; AVX512DQ-NEXT: vpmovsxwd %ymm1, %zmm1
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
[X86] Add DAG combine to promote vXi1 result of a vXi8/vXi16 setcc when we have AVX512 but not BWI. This avoids having the result type stick around until lowering where we have to extend the setcc and insert a truncate. If we get the types converted early we can do more to optimize it. llvm-svn: 322432
2018-01-13 14:24:46 +08:00
; AVX512DQ-NEXT: vpmovsxwd %ymm2, %zmm2
; AVX512DQ-NEXT: vpmovdb %zmm2, %xmm2
; AVX512DQ-NEXT: vpmovsxwd %ymm3, %zmm3
; AVX512DQ-NEXT: vpmovdb %zmm3, %xmm3
[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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled. Similar for vXi16/vXi8 with BWI. Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization. llvm-svn: 319059
2017-11-28 01:51:55 +08:00
; AVX512BW-NEXT: vpcmpgtw %zmm2, %zmm0, %k0
; AVX512BW-NEXT: vpcmpgtw %zmm3, %zmm1, %k1
; AVX512BW-NEXT: kunpckdq %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
[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 <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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.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
; 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)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 14(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm6, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 12(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm5, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 10(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm4, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 8(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm3, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 6(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm2, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 4(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm1, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled. Recommiting with compiler time improvements Recommitting 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: 297695
2017-03-14 08:34:14 +08:00
; SSE2-NEXT: movdqa %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: popq %rcx
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v128i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.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: 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 $1, %xmm7, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm7, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm7, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm7, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm7, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm6, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm6, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm6, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm6, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm6, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm5, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm5, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm5, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm5, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm5, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm4, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm4, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm4, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm4, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm4, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm4, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm4, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm4, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm3, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm3, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm3, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm3, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm3, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm2, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm2, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm2, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm2, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm1, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm1, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm1, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm1, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 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
; SSE42-NEXT: pextrb $1, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
; SSE42-NEXT: pextrb $2, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
; SSE42-NEXT: pextrb $3, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
; SSE42-NEXT: pextrb $4, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
; SSE42-NEXT: pextrb $5, %xmm0, %eax
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
; SSE42-NEXT: pextrb $6, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
; SSE42-NEXT: pextrb $7, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $8, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $9, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $10, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $11, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $12, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $13, %xmm0, %edx
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: pextrb $14, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
; SSE42-NEXT: pextrb $15, %xmm0, %edx
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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
; SSE42-NEXT: movq %rdi, %rax
; SSE42-NEXT: retq
;
; AVX1-LABEL: test_cmp_v128i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.0:
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm4, %xmm8
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm9
; AVX1-NEXT: vpcmpgtb %xmm8, %xmm9, %xmm8
; AVX1-NEXT: vpcmpgtb %xmm4, %xmm0, %xmm9
; AVX1-NEXT: vextractf128 $1, %ymm5, %xmm4
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm0
; AVX1-NEXT: vpcmpgtb %xmm4, %xmm0, %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
; AVX1-NEXT: vpcmpgtb %xmm5, %xmm1, %xmm1
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm6, %xmm0
; AVX1-NEXT: vextractf128 $1, %ymm2, %xmm5
; AVX1-NEXT: vpcmpgtb %xmm0, %xmm5, %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
; AVX1-NEXT: vpcmpgtb %xmm6, %xmm2, %xmm2
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm7, %xmm0
; AVX1-NEXT: vextractf128 $1, %ymm3, %xmm6
; AVX1-NEXT: vpcmpgtb %xmm0, %xmm6, %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
; AVX1-NEXT: vpcmpgtb %xmm7, %xmm3, %xmm3
; AVX1-NEXT: vpextrb $1, %xmm3, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: vpextrb $0, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $2, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $3, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $4, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $5, %xmm3, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $6, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $7, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm3, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm3, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $1, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $2, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $3, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $5, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $6, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $7, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm6, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm6, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm6, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, 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
; AVX1-NEXT: vpextrb $1, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: vpextrb $0, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $2, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $3, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $4, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $5, %xmm2, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $6, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $7, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm2, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm2, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $1, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $2, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $3, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $5, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $6, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $7, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm5, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm5, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm5, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, 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
; AVX1-NEXT: vpextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: vpextrb $0, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $2, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $3, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $4, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $5, %xmm1, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $6, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $7, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm1, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm1, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $1, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $2, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $3, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $5, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $6, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $7, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm4, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm4, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm4, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, 4(%rdi)
; AVX1-NEXT: vpextrb $1, %xmm9, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: vpextrb $0, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rcx,%rax,2), %eax
; AVX1-NEXT: vpextrb $2, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,4), %eax
; AVX1-NEXT: vpextrb $3, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: leal (%rax,%rcx,8), %eax
; AVX1-NEXT: vpextrb $4, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $4, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpextrb $5, %xmm9, %eax
; AVX1-NEXT: andl $1, %eax
; AVX1-NEXT: shll $5, %eax
; AVX1-NEXT: orl %ecx, %eax
; AVX1-NEXT: vpextrb $6, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $6, %ecx
; AVX1-NEXT: vpextrb $7, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $7, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $8, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $9, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $10, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $11, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $12, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $13, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm9, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $14, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm9, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $15, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $0, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $16, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $1, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $17, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $2, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $18, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $3, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $19, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $4, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $20, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $5, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $21, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $6, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $22, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $7, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $23, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $8, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $24, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $9, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $25, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $10, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $26, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $11, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $27, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $12, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $28, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $13, %xmm8, %edx
; AVX1-NEXT: andl $1, %edx
; AVX1-NEXT: shll $29, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: vpextrb $14, %xmm8, %ecx
; AVX1-NEXT: andl $1, %ecx
; AVX1-NEXT: shll $30, %ecx
; AVX1-NEXT: orl %edx, %ecx
; AVX1-NEXT: vpextrb $15, %xmm8, %edx
; AVX1-NEXT: shll $31, %edx
; AVX1-NEXT: orl %ecx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: movl %edx, (%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
; AVX1-NEXT: movq %rdi, %rax
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: test_cmp_v128i8:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.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
; 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: vpextrb $1, %xmm3, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: vpextrb $0, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $2, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $3, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $4, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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 $5, %xmm3, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $6, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $7, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vextracti128 $1, %ymm3, %xmm3
; AVX2-NEXT: vpextrb $0, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $1, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $2, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $3, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $5, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $6, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $7, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm3, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm3, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm3, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, 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
; AVX2-NEXT: vpextrb $1, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: vpextrb $0, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $2, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $3, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $4, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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 $5, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $6, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $7, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vextracti128 $1, %ymm2, %xmm2
; AVX2-NEXT: vpextrb $0, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $1, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $2, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $3, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $5, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $6, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $7, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm2, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm2, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm2, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, 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
; AVX2-NEXT: vpextrb $1, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: vpextrb $0, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $2, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $3, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $4, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
[X86][SSE] Added 1024-bit vector comparison tests More examples of PR22603, poor 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 $5, %xmm1, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $6, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $7, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vextracti128 $1, %ymm1, %xmm1
; AVX2-NEXT: vpextrb $0, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $1, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $2, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $3, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $5, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $6, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $7, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm1, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm1, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm1, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, 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
; AVX2-NEXT: vpextrb $1, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: vpextrb $0, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rcx,%rax,2), %eax
; AVX2-NEXT: vpextrb $2, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,4), %eax
; AVX2-NEXT: vpextrb $3, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: leal (%rax,%rcx,8), %eax
; AVX2-NEXT: vpextrb $4, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $4, %ecx
; AVX2-NEXT: orl %eax, %ecx
; AVX2-NEXT: vpextrb $5, %xmm0, %eax
; AVX2-NEXT: andl $1, %eax
; AVX2-NEXT: shll $5, %eax
; AVX2-NEXT: orl %ecx, %eax
; AVX2-NEXT: vpextrb $6, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $6, %ecx
; AVX2-NEXT: vpextrb $7, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $7, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $8, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $9, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $10, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $11, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $12, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $13, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $14, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $15, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX2-NEXT: vpextrb $0, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $16, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $1, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $17, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $2, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $18, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $3, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $19, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $4, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $20, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $5, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $21, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $6, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $22, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $7, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $23, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $8, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $24, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $9, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $25, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $10, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $26, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $11, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $27, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $12, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $28, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $13, %xmm0, %edx
; AVX2-NEXT: andl $1, %edx
; AVX2-NEXT: shll $29, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: vpextrb $14, %xmm0, %ecx
; AVX2-NEXT: andl $1, %ecx
; AVX2-NEXT: shll $30, %ecx
; AVX2-NEXT: orl %edx, %ecx
; AVX2-NEXT: vpextrb $15, %xmm0, %edx
; AVX2-NEXT: shll $31, %edx
; AVX2-NEXT: orl %ecx, %edx
; AVX2-NEXT: orl %eax, %edx
; AVX2-NEXT: movl %edx, (%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
; 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[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: vpcmpgtb %ymm4, %ymm0, %ymm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm4
[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: vptestmd %zmm4, %zmm4, %k0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm0
; AVX512F-NEXT: vptestmd %zmm0, %zmm0, %k1
; AVX512F-NEXT: vpcmpgtb %ymm5, %ymm1, %ymm0
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm1
; AVX512F-NEXT: vptestmd %zmm1, %zmm1, %k2
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm0
[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: vpmovsxbd %xmm0, %zmm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vptestmd %zmm0, %zmm0, %k3
; AVX512F-NEXT: vpcmpgtb %ymm6, %ymm2, %ymm0
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm1
; AVX512F-NEXT: vptestmd %zmm1, %zmm1, %k4
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm0
; AVX512F-NEXT: vptestmd %zmm0, %zmm0, %k5
; AVX512F-NEXT: vpcmpgtb %ymm7, %ymm3, %ymm0
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm1
; AVX512F-NEXT: vptestmd %zmm1, %zmm1, %k6
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX512F-NEXT: vpmovsxbd %xmm0, %zmm0
; AVX512F-NEXT: vptestmd %zmm0, %zmm0, %k7
; AVX512F-NEXT: kmovw %k7, 14(%rdi)
; AVX512F-NEXT: kmovw %k6, 12(%rdi)
; AVX512F-NEXT: kmovw %k5, 10(%rdi)
; AVX512F-NEXT: kmovw %k4, 8(%rdi)
; AVX512F-NEXT: kmovw %k3, 6(%rdi)
; AVX512F-NEXT: kmovw %k2, 4(%rdi)
; AVX512F-NEXT: kmovw %k1, 2(%rdi)
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[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: vpcmpgtb %ymm4, %ymm0, %ymm0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm4
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm4, %k0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm0
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm0, %k1
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vpcmpgtb %ymm5, %ymm1, %ymm0
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm1
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm1, %k2
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm0
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm0, %k3
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vpcmpgtb %ymm6, %ymm2, %ymm0
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm1
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm1, %k4
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm0
[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: vpmovsxbd %xmm0, %zmm0
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm0, %k5
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vpcmpgtb %ymm7, %ymm3, %ymm0
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm1
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm1, %k6
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vextracti128 $1, %ymm0, %xmm0
; AVX512DQ-NEXT: vpmovsxbd %xmm0, %zmm0
[X86] Use vpmovq2m/vpmovd2m for truncate to vXi1 when possible. Previously we used vptestmd, but the scheduling data for SKX says vpmovq2m/vpmovd2m is lower latency. We already used vpmovb2m/vpmovw2m for byte/word truncates. So this is more consistent anyway. llvm-svn: 325534
2018-02-20 06:07:31 +08:00
; AVX512DQ-NEXT: vpmovd2m %zmm0, %k7
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: kmovw %k7, 14(%rdi)
; AVX512DQ-NEXT: kmovw %k6, 12(%rdi)
; AVX512DQ-NEXT: kmovw %k5, 10(%rdi)
; AVX512DQ-NEXT: kmovw %k4, 8(%rdi)
; AVX512DQ-NEXT: kmovw %k3, 6(%rdi)
; AVX512DQ-NEXT: kmovw %k2, 4(%rdi)
; AVX512DQ-NEXT: kmovw %k1, 2(%rdi)
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.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
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm8
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: cmpltpd %xmm1, %xmm8
[SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
2017-09-19 00:45:05 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm1
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: cmpltpd %xmm0, %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movapd {{.*#+}} xmm9 = [255,255]
; SSE2-NEXT: andpd %xmm9, %xmm8
; SSE2-NEXT: andpd %xmm9, %xmm1
; SSE2-NEXT: packuswb %xmm8, %xmm1
[X86] Redefine MOVSS/MOVSD instructions to take VR128 regclass as input instead of FR32/FR64 This patch redefines the MOVSS/MOVSD instructions to take VR128 as its second input. This allows the MOVSS/SD->BLEND commute to work without requiring a COPY to be inserted. This should fix PR33079 Overall this looks to be an improvement in the generated code. I haven't checked the EXPENSIVE_CHECKS build but I'll do that and update with results. Differential Revision: https://reviews.llvm.org/D38449 llvm-svn: 314914
2017-10-05 01:20:12 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: cmpltpd %xmm3, %xmm0
[X86] Redefine MOVSS/MOVSD instructions to take VR128 regclass as input instead of FR32/FR64 This patch redefines the MOVSS/MOVSD instructions to take VR128 as its second input. This allows the MOVSS/SD->BLEND commute to work without requiring a COPY to be inserted. This should fix PR33079 Overall this looks to be an improvement in the generated code. I haven't checked the EXPENSIVE_CHECKS build but I'll do that and update with results. Differential Revision: https://reviews.llvm.org/D38449 llvm-svn: 314914
2017-10-05 01:20:12 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: cmpltpd %xmm2, %xmm3
; SSE2-NEXT: andpd %xmm9, %xmm0
; SSE2-NEXT: andpd %xmm9, %xmm3
; SSE2-NEXT: packuswb %xmm0, %xmm3
; SSE2-NEXT: packuswb %xmm1, %xmm1
; SSE2-NEXT: packuswb %xmm1, %xmm1
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm3[1,1,2,3]
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: cmpltpd %xmm7, %xmm0
[X86] Redefine MOVSS/MOVSD instructions to take VR128 regclass as input instead of FR32/FR64 This patch redefines the MOVSS/MOVSD instructions to take VR128 as its second input. This allows the MOVSS/SD->BLEND commute to work without requiring a COPY to be inserted. This should fix PR33079 Overall this looks to be an improvement in the generated code. I haven't checked the EXPENSIVE_CHECKS build but I'll do that and update with results. Differential Revision: https://reviews.llvm.org/D38449 llvm-svn: 314914
2017-10-05 01:20:12 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: cmpltpd %xmm6, %xmm3
; SSE2-NEXT: andpd %xmm9, %xmm0
; SSE2-NEXT: andpd %xmm9, %xmm3
; SSE2-NEXT: packuswb %xmm0, %xmm3
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: cmpltpd %xmm5, %xmm0
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm6
; SSE2-NEXT: cmpltpd %xmm4, %xmm6
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: andpd %xmm9, %xmm0
; SSE2-NEXT: andpd %xmm9, %xmm6
; SSE2-NEXT: packuswb %xmm0, %xmm6
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: packuswb %xmm6, %xmm6
; SSE2-NEXT: packuswb %xmm6, %xmm6
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm6[0,1,2,2]
; SSE2-NEXT: punpckhdq {{.*#+}} xmm4 = xmm4[2],xmm3[2],xmm4[3],xmm3[3]
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movsd {{.*#+}} xmm4 = xmm1[0],xmm4[1]
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: andpd %xmm9, %xmm0
[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
2017-10-28 22:27:53 +08:00
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm3
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andpd %xmm9, %xmm3
; SSE2-NEXT: packuswb %xmm0, %xmm3
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: andpd %xmm9, %xmm0
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm5
; SSE2-NEXT: andpd %xmm9, %xmm5
; SSE2-NEXT: packuswb %xmm0, %xmm5
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: packuswb %xmm5, %xmm5
; SSE2-NEXT: packuswb %xmm5, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm5[1,1,2,3]
; SSE2-NEXT: punpckldq {{.*#+}} xmm3 = xmm3[0],xmm0[0],xmm3[1],xmm0[1]
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: andpd %xmm9, %xmm0
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: andpd %xmm9, %xmm1
; SSE2-NEXT: packuswb %xmm0, %xmm1
; SSE2-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: andpd %xmm9, %xmm0
; SSE2-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: andpd %xmm9, %xmm2
; SSE2-NEXT: packuswb %xmm0, %xmm2
; SSE2-NEXT: packuswb %xmm1, %xmm1
; SSE2-NEXT: packuswb %xmm1, %xmm1
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[0,1,2,2]
; SSE2-NEXT: punpckhdq {{.*#+}} xmm0 = xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; SSE2-NEXT: movsd {{.*#+}} xmm0 = xmm3[0],xmm0[1]
; SSE2-NEXT: movapd %xmm0, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movapd %xmm4, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.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: pushq %rbp
; SSE42-NEXT: pushq %r15
; SSE42-NEXT: pushq %r14
; SSE42-NEXT: pushq %r13
; SSE42-NEXT: pushq %r12
; SSE42-NEXT: pushq %rbx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: movq %rdi, -{{[0-9]+}}(%rsp) # 8-byte Spill
[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), %xmm8
Revert r322279 due to Skylake miscompile. Summary: This revision causes Skylake (and apparently, only Skylake) codegen to fail in certain cases. Details: https://bugs.llvm.org/show_bug.cgi?id=35918 Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D41972 llvm-svn: 322335
2018-01-12 08:17:38 +08:00
; SSE42-NEXT: cmpltpd %xmm7, %xmm8
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm7
; SSE42-NEXT: cmpltpd %xmm6, %xmm7
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: cmpltpd %xmm5, %xmm6
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: cmpltpd %xmm4, %xmm5
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: cmpltpd %xmm3, %xmm4
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: cmpltpd %xmm2, %xmm3
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: cmpltpd %xmm1, %xmm2
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. llvm-svn: 322279
2018-01-11 22:25:18 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm1
Revert r322279 due to Skylake miscompile. Summary: This revision causes Skylake (and apparently, only Skylake) codegen to fail in certain cases. Details: https://bugs.llvm.org/show_bug.cgi?id=35918 Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D41972 llvm-svn: 322335
2018-01-12 08:17:38 +08:00
; SSE42-NEXT: cmpltpd %xmm0, %xmm1
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %r8d
; SSE42-NEXT: pextrb $0, %xmm0, %r10d
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pextrb $0, %xmm0, %ebp
; SSE42-NEXT: pextrb $8, %xmm0, %edi
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pextrb $0, %xmm0, %r15d
; SSE42-NEXT: pextrb $8, %xmm0, %r11d
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pextrb $0, %xmm0, %r14d
; SSE42-NEXT: pextrb $8, %xmm0, %r9d
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pextrb $0, %xmm0, %esi
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %r12d
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pextrb $0, %xmm0, %edx
; SSE42-NEXT: pextrb $8, %xmm0, %ebx
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: pextrb $0, %xmm0, %eax
; SSE42-NEXT: pextrb $8, %xmm0, %r13d
; SSE42-NEXT: movapd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: cmpltpd {{[0-9]+}}(%rsp), %xmm0
; SSE42-NEXT: andl $1, %r8d
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %r10d
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: leal (%r10,%r8,2), %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ebp
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: leal (%rcx,%rbp,4), %r8d
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: pextrb $8, %xmm0, %ebp
; SSE42-NEXT: andl $1, %edi
; SSE42-NEXT: leal (%r8,%rdi,8), %r8d
; SSE42-NEXT: andl $1, %r15d
; SSE42-NEXT: shll $4, %r15d
; SSE42-NEXT: orl %r8d, %r15d
; SSE42-NEXT: pextrb $8, %xmm1, %edi
; SSE42-NEXT: movq %rdi, -{{[0-9]+}}(%rsp) # 8-byte Spill
; SSE42-NEXT: pextrb $0, %xmm1, %r10d
; SSE42-NEXT: andl $1, %r11d
; SSE42-NEXT: shll $5, %r11d
; SSE42-NEXT: orl %r15d, %r11d
; SSE42-NEXT: andl $1, %r14d
; SSE42-NEXT: shll $6, %r14d
; SSE42-NEXT: andl $1, %r9d
; SSE42-NEXT: shll $7, %r9d
; SSE42-NEXT: orl %r14d, %r9d
; SSE42-NEXT: pextrb $0, %xmm2, %r14d
; SSE42-NEXT: pextrb $8, %xmm2, %edi
; SSE42-NEXT: movq %rdi, -{{[0-9]+}}(%rsp) # 8-byte Spill
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %esi
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $8, %esi
; SSE42-NEXT: orl %r9d, %esi
; SSE42-NEXT: andl $1, %r12d
; SSE42-NEXT: shll $9, %r12d
; SSE42-NEXT: orl %esi, %r12d
; SSE42-NEXT: pextrb $0, %xmm3, %r8d
; SSE42-NEXT: pextrb $8, %xmm3, %r15d
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $10, %edx
; SSE42-NEXT: orl %r12d, %edx
; SSE42-NEXT: andl $1, %ebx
; SSE42-NEXT: shll $11, %ebx
; SSE42-NEXT: orl %edx, %ebx
; SSE42-NEXT: pextrb $0, %xmm4, %r12d
; SSE42-NEXT: pextrb $8, %xmm4, %edi
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $12, %eax
; SSE42-NEXT: orl %ebx, %eax
; SSE42-NEXT: andl $1, %r13d
; SSE42-NEXT: shll $13, %r13d
; SSE42-NEXT: orl %eax, %r13d
; SSE42-NEXT: pextrb $0, %xmm5, %eax
; SSE42-NEXT: pextrb $8, %xmm5, %ebx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %r13d, %ecx
; SSE42-NEXT: shll $15, %ebp
; SSE42-NEXT: orl %ecx, %ebp
; SSE42-NEXT: pextrb $0, %xmm6, %r13d
; SSE42-NEXT: pextrb $8, %xmm6, %edx
; SSE42-NEXT: orl %r11d, %ebp
; SSE42-NEXT: movq -{{[0-9]+}}(%rsp), %r9 # 8-byte Reload
; SSE42-NEXT: movw %bp, 2(%r9)
; SSE42-NEXT: pextrb $0, %xmm7, %r11d
; SSE42-NEXT: pextrb $8, %xmm7, %ecx
; SSE42-NEXT: movq -{{[0-9]+}}(%rsp), %rsi # 8-byte Reload
; SSE42-NEXT: andl $1, %esi
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %r10d
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: leal (%r10,%rsi,2), %esi
; SSE42-NEXT: andl $1, %r14d
; SSE42-NEXT: leal (%rsi,%r14,4), %r14d
; SSE42-NEXT: pextrb $0, %xmm8, %r10d
; SSE42-NEXT: pextrb $8, %xmm8, %ebp
; SSE42-NEXT: movq -{{[0-9]+}}(%rsp), %rsi # 8-byte Reload
; SSE42-NEXT: andl $1, %esi
; SSE42-NEXT: leal (%r14,%rsi,8), %esi
; SSE42-NEXT: andl $1, %r8d
; SSE42-NEXT: shll $4, %r8d
; SSE42-NEXT: orl %esi, %r8d
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %r15d
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $5, %r15d
; SSE42-NEXT: orl %r8d, %r15d
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %r12d
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $6, %r12d
; SSE42-NEXT: andl $1, %edi
; SSE42-NEXT: shll $7, %edi
; SSE42-NEXT: orl %r12d, %edi
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $8, %eax
; SSE42-NEXT: orl %edi, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ebx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $9, %ebx
; SSE42-NEXT: orl %eax, %ebx
; SSE42-NEXT: andl $1, %r13d
; SSE42-NEXT: shll $10, %r13d
; SSE42-NEXT: orl %ebx, %r13d
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %r13d, %edx
; SSE42-NEXT: andl $1, %r11d
; SSE42-NEXT: shll $12, %r11d
; SSE42-NEXT: orl %edx, %r11d
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: shll $13, %ecx
; SSE42-NEXT: orl %r11d, %ecx
; SSE42-NEXT: andl $1, %r10d
; SSE42-NEXT: shll $14, %r10d
; SSE42-NEXT: orl %ecx, %r10d
; SSE42-NEXT: shll $15, %ebp
; SSE42-NEXT: orl %r10d, %ebp
; SSE42-NEXT: orl %r15d, %ebp
; SSE42-NEXT: movw %bp, (%r9)
; SSE42-NEXT: movq %r9, %rax
[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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm7, %xmm15, %xmm15
[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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpackssdw %xmm15, %xmm6, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm7, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm7, %xmm4, %xmm4
; AVX1-NEXT: vpackssdw %xmm5, %xmm4, %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
; 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm5, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm5, %xmm2, %xmm2
; AVX1-NEXT: vpackssdw %xmm3, %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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: 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpackssdw %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] 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm7, %ymm6, %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
; AVX2-NEXT: vpermq {{.*#+}} ymm6 = ymm6[0,2,1,3]
; AVX2-NEXT: vcmpltpd %ymm5, %ymm13, %ymm5
; AVX2-NEXT: vcmpltpd %ymm4, %ymm12, %ymm4
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm5, %ymm4, %ymm4
[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: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm6, %ymm4, %ymm4
[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: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
; AVX2-NEXT: vcmpltpd %ymm3, %ymm11, %ymm3
; AVX2-NEXT: vcmpltpd %ymm2, %ymm10, %ymm2
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm3, %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: vpermq {{.*#+}} ymm2 = ymm2[0,2,1,3]
; AVX2-NEXT: vcmpltpd %ymm1, %ymm9, %ymm1
; AVX2-NEXT: vcmpltpd %ymm0, %ymm8, %ymm0
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vcmpltpd %zmm2, %zmm6, %k0
; AVX512F-NEXT: vcmpltpd %zmm3, %zmm7, %k1
; AVX512F-NEXT: kunpckbw %k0, %k1, %k1
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vcmpltpd %zmm0, %zmm4, %k0
; AVX512F-NEXT: vcmpltpd %zmm1, %zmm5, %k2
; AVX512F-NEXT: kunpckbw %k0, %k2, %k2
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k2} {z}
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm1, %zmm1, %zmm1 {%k1} {z}
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[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_v32f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512DQ-NEXT: vcmpltpd %zmm2, %zmm6, %k0
; AVX512DQ-NEXT: vcmpltpd %zmm3, %zmm7, %k1
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: kunpckbw %k0, %k1, %k0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vcmpltpd %zmm0, %zmm4, %k1
; AVX512DQ-NEXT: vcmpltpd %zmm1, %zmm5, %k2
; AVX512DQ-NEXT: kunpckbw %k1, %k2, %k1
; AVX512DQ-NEXT: vpmovm2d %k1, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm1
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[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_v32f64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512BW-NEXT: vcmpltpd %zmm0, %zmm4, %k0
; AVX512BW-NEXT: vcmpltpd %zmm1, %zmm5, %k1
; AVX512BW-NEXT: kunpckbw %k0, %k1, %k0
; AVX512BW-NEXT: vcmpltpd %zmm2, %zmm6, %k1
; AVX512BW-NEXT: vcmpltpd %zmm3, %zmm7, %k2
; AVX512BW-NEXT: kunpckbw %k1, %k2, %k1
; AVX512BW-NEXT: kunpckwd %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $ymm0 killed $ymm0 killed $zmm0
[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 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE2: # %bb.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
; SSE2-NEXT: movdqa {{.*#+}} xmm8 = [2147483648,0,2147483648,0]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; 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), %xmm9
; SSE2-NEXT: pxor %xmm8, %xmm9
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa %xmm1, %xmm10
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pcmpgtd %xmm9, %xmm10
; SSE2-NEXT: pshufd {{.*#+}} xmm11 = xmm10[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm1, %xmm9
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm9[1,1,3,3]
; SSE2-NEXT: pand %xmm11, %xmm1
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm10[1,1,3,3]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: por %xmm1, %xmm9
; SSE2-NEXT: movdqa {{.*#+}} xmm10 = [255,255]
; SSE2-NEXT: pand %xmm10, %xmm9
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pxor %xmm8, %xmm0
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa %xmm0, %xmm11
; SSE2-NEXT: pcmpgtd %xmm1, %xmm11
; SSE2-NEXT: pshufd {{.*#+}} xmm12 = xmm11[0,0,2,2]
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm12, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm11 = xmm11[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm11
; SSE2-NEXT: pand %xmm10, %xmm11
; SSE2-NEXT: packuswb %xmm9, %xmm11
; SSE2-NEXT: packuswb %xmm11, %xmm11
; SSE2-NEXT: packuswb %xmm11, %xmm11
; SSE2-NEXT: pxor %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
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa %xmm3, %xmm0
; SSE2-NEXT: pcmpgtd %xmm1, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm0[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm9, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm0
; SSE2-NEXT: pand %xmm10, %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: pxor %xmm8, %xmm2
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: movdqa %xmm2, %xmm3
; SSE2-NEXT: pcmpgtd %xmm1, %xmm3
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm9 = xmm3[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm2, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm9, %xmm1
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm3[1,1,3,3]
; SSE2-NEXT: por %xmm1, %xmm2
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pand %xmm10, %xmm2
; SSE2-NEXT: packuswb %xmm0, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[1,1,2,3]
; SSE2-NEXT: punpckldq {{.*#+}} xmm11 = xmm11[0],xmm0[0],xmm11[1],xmm0[1]
; SSE2-NEXT: pxor %xmm8, %xmm7
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: movdqa %xmm7, %xmm1
; SSE2-NEXT: pcmpgtd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm1[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm7, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm2, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm1
; SSE2-NEXT: pand %xmm10, %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm6
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: movdqa %xmm6, %xmm2
; SSE2-NEXT: pcmpgtd %xmm0, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm2[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm6, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm3, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm2[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm2
; SSE2-NEXT: pand %xmm10, %xmm2
; SSE2-NEXT: packuswb %xmm1, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: pxor %xmm8, %xmm5
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: movdqa %xmm5, %xmm1
; SSE2-NEXT: pcmpgtd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm1[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm5, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm3, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm1
; SSE2-NEXT: pand %xmm10, %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: movdqa %xmm4, %xmm3
; SSE2-NEXT: pcmpgtd %xmm0, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm3[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm4, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm3
; SSE2-NEXT: pand %xmm10, %xmm3
; SSE2-NEXT: packuswb %xmm1, %xmm3
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: packuswb %xmm3, %xmm3
; SSE2-NEXT: pshufd {{.*#+}} xmm3 = xmm3[0,1,2,2]
; SSE2-NEXT: punpckhdq {{.*#+}} xmm3 = xmm3[2],xmm2[2],xmm3[3],xmm2[3]
; SSE2-NEXT: movsd {{.*#+}} xmm3 = xmm11[0],xmm3[1]
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa %xmm1, %xmm2
; SSE2-NEXT: pcmpgtd %xmm0, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm2[0,0,2,2]
; SSE2-NEXT: pcmpeqd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm4, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm1
; SSE2-NEXT: pand %xmm10, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm2
; SSE2-NEXT: pxor %xmm8, %xmm2
; SSE2-NEXT: movdqa %xmm2, %xmm4
; SSE2-NEXT: pcmpgtd %xmm0, %xmm4
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm2
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm2[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm2
; SSE2-NEXT: pand %xmm10, %xmm2
; SSE2-NEXT: packuswb %xmm1, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: packuswb %xmm2, %xmm2
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movdqa %xmm1, %xmm4
; SSE2-NEXT: pcmpgtd %xmm0, %xmm4
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm1
; SSE2-NEXT: pand %xmm10, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa %xmm4, %xmm5
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpgtd %xmm0, %xmm5
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm0
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: por %xmm0, %xmm4
; SSE2-NEXT: pand %xmm10, %xmm4
; SSE2-NEXT: packuswb %xmm1, %xmm4
; SSE2-NEXT: packuswb %xmm4, %xmm4
; SSE2-NEXT: packuswb %xmm4, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm4[1,1,2,3]
; SSE2-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm0[0],xmm2[1],xmm0[1]
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
; SSE2-NEXT: movdqa %xmm1, %xmm4
; SSE2-NEXT: pcmpgtd %xmm0, %xmm4
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
; SSE2-NEXT: pand %xmm5, %xmm0
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm4[1,1,3,3]
; SSE2-NEXT: por %xmm0, %xmm1
; SSE2-NEXT: pand %xmm10, %xmm1
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
; SSE2-NEXT: pxor %xmm8, %xmm0
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa %xmm4, %xmm5
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpgtd %xmm0, %xmm5
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm0, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm4[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm5[1,1,3,3]
; SSE2-NEXT: por %xmm4, %xmm0
; SSE2-NEXT: pand %xmm10, %xmm0
; SSE2-NEXT: packuswb %xmm1, %xmm0
; SSE2-NEXT: packuswb %xmm0, %xmm0
; SSE2-NEXT: packuswb %xmm0, %xmm0
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm4
; SSE2-NEXT: pxor %xmm8, %xmm4
; SSE2-NEXT: movdqa %xmm4, %xmm5
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpgtd %xmm1, %xmm5
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm1, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm4[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm5[1,1,3,3]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: por %xmm1, %xmm4
; SSE2-NEXT: pand %xmm10, %xmm4
; SSE2-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm1
; SSE2-NEXT: pxor %xmm8, %xmm1
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pxor {{[0-9]+}}(%rsp), %xmm8
; SSE2-NEXT: movdqa %xmm8, %xmm5
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpgtd %xmm1, %xmm5
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm6 = xmm5[0,0,2,2]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: pcmpeqd %xmm1, %xmm8
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm8[1,1,3,3]
; SSE2-NEXT: pand %xmm6, %xmm1
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE2-NEXT: pshufd {{.*#+}} xmm5 = xmm5[1,1,3,3]
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: por %xmm1, %xmm5
; SSE2-NEXT: pand %xmm10, %xmm5
; SSE2-NEXT: packuswb %xmm4, %xmm5
; SSE2-NEXT: packuswb %xmm5, %xmm5
; SSE2-NEXT: packuswb %xmm5, %xmm5
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm5[0,1,2,2]
; SSE2-NEXT: punpckhdq {{.*#+}} xmm1 = xmm1[2],xmm0[2],xmm1[3],xmm0[3]
; SSE2-NEXT: movsd {{.*#+}} xmm1 = xmm2[0],xmm1[1]
; SSE2-NEXT: movapd %xmm1, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, 2(%rdi)
[SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc. Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type. But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86. This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck. This patch tries to fix this by detecting the getSetccResultType needs to be promoted. If its input type also needs to be promoted we'll try a ask for a new setcc result type based on its eventual promoted value. Otherwise we fall back to default type to promote to. For any other illegal values we might get back from the initial call to getSetccResultType we just keep and allow it to be re-legalized later via splitting or widening or scalarizing. llvm-svn: 327683
2018-03-16 07:04:11 +08:00
; SSE2-NEXT: movapd %xmm3, -{{[0-9]+}}(%rsp)
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rcx,%rax,2), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,4), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: leal (%rax,%rcx,8), %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $4, %ecx
; SSE2-NEXT: orl %eax, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %eax
; SSE2-NEXT: andl $1, %eax
; SSE2-NEXT: shll $5, %eax
; SSE2-NEXT: orl %ecx, %eax
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $6, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $7, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $8, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $9, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $10, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $11, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $12, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: andl $1, %edx
; SSE2-NEXT: shll $13, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %ecx
; SSE2-NEXT: andl $1, %ecx
; SSE2-NEXT: shll $14, %ecx
; SSE2-NEXT: orl %edx, %ecx
; SSE2-NEXT: movzbl -{{[0-9]+}}(%rsp), %edx
; SSE2-NEXT: shll $15, %edx
; SSE2-NEXT: orl %ecx, %edx
; SSE2-NEXT: orl %eax, %edx
; SSE2-NEXT: movw %dx, (%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: movq %rdi, %rax
; SSE2-NEXT: retq
;
; SSE42-LABEL: test_cmp_v32i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; SSE42: # %bb.0:
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm15
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm14
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm13
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm12
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm11
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm10
[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split. llvm-svn: 319010
2017-11-27 13:52:54 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm9
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm8
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. llvm-svn: 322279
2018-01-11 22:25:18 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm7
Revert r322279 due to Skylake miscompile. Summary: This revision causes Skylake (and apparently, only Skylake) codegen to fail in certain cases. Details: https://bugs.llvm.org/show_bug.cgi?id=35918 Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D41972 llvm-svn: 322335
2018-01-12 08:17:38 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm6
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm5
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm4
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm3
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm2
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm1
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm0
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm8
[X86][SSE] Add support for lowering shuffles to PACKSS/PACKUS If the upper bits of a truncation shuffle patterns have at least the minimum number of sign/zero bits on their inputs then we can safely use PACKSS/PACKUS as shuffles. Partial fix for https://bugs.llvm.org/show_bug.cgi?id=34773 Differential Revision: https://reviews.llvm.org/D38472 llvm-svn: 314788
2017-10-03 20:01:31 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm9
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm10
[SelectionDAG] When legalizing the result type of CONCAT_VECTORS, take into account whether the input type also needs to be promoted. If so go ahead and get the promoted input vector to extract from. Previously, we would create a bunch of any_extends of extract_vector_elts with illegal input type that needs to be promoted. The legalization of those extract_vector_elts would then potentially introduce a truncate. So now we have a bunch of any_extends of truncates. By legalizing both parts together we avoid creating these extra nodes. The test changes seem to be because we were previously combining the build_vector with the any_extend before the any_extend got combined with the truncate. llvm-svn: 320669
2017-12-14 14:49:07 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm11
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm12
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm13
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm14
; SSE42-NEXT: pcmpgtq {{[0-9]+}}(%rsp), %xmm15
; SSE42-NEXT: pextrb $8, %xmm15, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm15, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm14, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm14, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm13, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm13, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm12, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm12, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm11, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm11, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm10, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm10, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm9, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm9, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm8, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm8, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, 2(%rdi)
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm0, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: pextrb $0, %xmm0, %ecx
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rcx,%rax,2), %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm1, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,4), %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm1, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: leal (%rax,%rcx,8), %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm2, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $4, %ecx
; SSE42-NEXT: orl %eax, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm2, %eax
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %eax
; SSE42-NEXT: shll $5, %eax
; SSE42-NEXT: orl %ecx, %eax
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm3, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $6, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm3, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $7, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm4, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $8, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm4, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $9, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm5, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $10, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm5, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $11, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm6, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $12, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm6, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %edx
; SSE42-NEXT: shll $13, %edx
; SSE42-NEXT: orl %ecx, %edx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $0, %xmm7, %ecx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: andl $1, %ecx
; SSE42-NEXT: shll $14, %ecx
; SSE42-NEXT: orl %edx, %ecx
[X86][SSE] Add ISD::VECTOR_SHUFFLE to faux shuffle decoding (Reapplied) Primarily, this allows us to use the aggressive extraction mechanisms in combineExtractWithShuffle earlier and make use of UNDEF elements that may be lost during lowering. Reapplied after rL322279 was reverted at rL322335 due to PR35918, underlying issue was fixed at rL322644. llvm-svn: 323104
2018-01-22 20:05:17 +08:00
; SSE42-NEXT: pextrb $8, %xmm7, %edx
[SelectionDAG] Fix codegen of vector stores with non byte-sized elements. This was completely broken, but hopefully fixed by this patch. In cases where it is needed, a vector with non byte-sized elements is stored by extracting, zero-extending, shift:ing and or:ing the elements into an integer of the same width as the vector, which is then stored. Review: Eli Friedman, Ulrich Weigand https://reviews.llvm.org/D42100#inline-369520 https://bugs.llvm.org/show_bug.cgi?id=35520 llvm-svn: 323042
2018-01-21 00:05:10 +08:00
; SSE42-NEXT: shll $15, %edx
; SSE42-NEXT: orl %ecx, %edx
; SSE42-NEXT: orl %eax, %edx
; SSE42-NEXT: movw %dx, (%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: retq
;
; AVX1-LABEL: test_cmp_v32i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX1: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm9, %xmm7, %xmm8
[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, %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm7, %xmm6, %xmm6
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm6, %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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm5, %xmm4, %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
; 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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm5, %xmm2, %xmm2
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %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] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX1-NEXT: vpackssdw %xmm3, %xmm0, %xmm0
; AVX1-NEXT: vpackssdw %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] 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX2: # %bb.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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm7, %ymm6, %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
; 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm5, %ymm4, %ymm4
[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: vpermq {{.*#+}} ymm4 = ymm4[0,2,1,3]
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm6, %ymm4, %ymm4
[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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %ymm3, %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: 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
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: vpermq {{.*#+}} ymm0 = ymm0[0,2,1,3]
[X86] truncateVectorCompareWithPACKSS - use PACKSSDW/PACKSSWB instead of just PACKSSWB. By using the widest type possible for PACKSS truncation we have a better chance of being able to peek through bitcasts and improves other combines driven by ComputeNumSignBits. llvm-svn: 316448
2017-10-24 23:38:16 +08:00
; AVX2-NEXT: vpackssdw %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: 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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512F: # %bb.0:
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vpcmpgtq %zmm6, %zmm2, %k0
; AVX512F-NEXT: vpcmpgtq %zmm7, %zmm3, %k1
; AVX512F-NEXT: kunpckbw %k0, %k1, %k1
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512F-NEXT: vpcmpgtq %zmm4, %zmm0, %k0
; AVX512F-NEXT: vpcmpgtq %zmm5, %zmm1, %k2
; AVX512F-NEXT: kunpckbw %k0, %k2, %k2
; AVX512F-NEXT: vpternlogd $255, %zmm0, %zmm0, %zmm0 {%k2} {z}
; AVX512F-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512F-NEXT: vpternlogd $255, %zmm1, %zmm1, %zmm1 {%k1} {z}
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512F-NEXT: vpmovdb %zmm1, %xmm1
; AVX512F-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[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_v32i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512DQ: # %bb.0:
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512DQ-NEXT: vpcmpgtq %zmm6, %zmm2, %k0
; AVX512DQ-NEXT: vpcmpgtq %zmm7, %zmm3, %k1
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: kunpckbw %k0, %k1, %k0
[X86] Legalize v32i1 without BWI via splitting to v16i1 rather than the default of promoting to v32i8. Summary: For the most part its better to keep v32i1 as a mask type of a narrower width than trying to promote it to a ymm register. I had to add some overrides to the methods that get the types for the calling convention so that we still use v32i8 for argument/return purposes. There are still some regressions in here. I definitely saw some around shuffles. I think we probably should move vXi1 shuffle from lowering to a DAG combine where I think the extend and truncate we have to emit would be better combined. I think we also need a DAG combine to remove trunc from (extract_vector_elt (trunc)) Overall this removes something like 13000 CHECK lines from lit tests. Reviewers: zvi, RKSimon, delena, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42031 llvm-svn: 323201
2018-01-23 22:25:39 +08:00
; AVX512DQ-NEXT: vpcmpgtq %zmm4, %zmm0, %k1
; AVX512DQ-NEXT: vpcmpgtq %zmm5, %zmm1, %k2
; AVX512DQ-NEXT: kunpckbw %k1, %k2, %k1
; AVX512DQ-NEXT: vpmovm2d %k1, %zmm0
; AVX512DQ-NEXT: vpmovdb %zmm0, %xmm0
[X86] Use SIGN_EXTEND to implement ANY_EXTEND from vXi1. llvm-svn: 321334
2017-12-22 10:30:26 +08:00
; AVX512DQ-NEXT: vpmovm2d %k0, %zmm1
[X86] Make ANY_EXTEND from vXi1 Custom for more types. We should be able to support ANY_EXTEND for any types we support ZERO_EXTEND for. llvm-svn: 320675
2017-12-14 16:26:00 +08:00
; AVX512DQ-NEXT: vpmovdb %zmm1, %xmm1
; AVX512DQ-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[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_v32i64:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; AVX512BW: # %bb.0:
[X86] Teach getSetCCResultType to handle more than just SimpleVTs when looking at larger than 512-bit vectors. Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added. llvm-svn: 319110
2017-11-28 06:56:10 +08:00
; AVX512BW-NEXT: vpcmpgtq %zmm4, %zmm0, %k0
; AVX512BW-NEXT: vpcmpgtq %zmm5, %zmm1, %k1
; AVX512BW-NEXT: kunpckbw %k0, %k1, %k0
; AVX512BW-NEXT: vpcmpgtq %zmm6, %zmm2, %k1
; AVX512BW-NEXT: vpcmpgtq %zmm7, %zmm3, %k2
; AVX512BW-NEXT: kunpckbw %k1, %k2, %k1
; AVX512BW-NEXT: kunpckwd %k0, %k1, %k0
; AVX512BW-NEXT: vpmovm2b %k0, %zmm0
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; AVX512BW-NEXT: # kill: def $ymm0 killed $ymm0 killed $zmm0
[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 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
}