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-half-conversions.ll

4413 lines
168 KiB
LLVM
Raw Normal View History

[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[X86][AVX512] Change VCVTSS2SD and VCVTSD2SS node types to keep consistency between VEX/EVEX versions. AVX versions of the converts work on f32/f64 types, while AVX512 version work on vectors. Differential Revision: https://reviews.llvm.org/D29988 llvm-svn: 295940
2017-02-23 15:24:21 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx,+f16c -verify-machineinstrs | FileCheck %s --check-prefix=ALL --check-prefix=AVX --check-prefix=AVX1
X86 Tests: Update more isel tests with FastVariableShuffle feature Summary: Added the FastVariableShuffle feature to cases that resembled processors for which this fearure is on. For AVX2 there are processors with and w/o this fearue enable. For AVX512 only KNL does enable this feature so cases which only have +avx512f were left without the FastVariableShuffle enabled. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41851 llvm-svn: 322090
2018-01-10 00:26:06 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx2,+f16c -verify-machineinstrs | FileCheck %s --check-prefixes=ALL,AVX,AVX2,AVX2-SLOW
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx2,+f16c,+fast-variable-shuffle -verify-machineinstrs | FileCheck %s --check-prefixes=ALL,AVX,AVX2,AVX2-FAST
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512f -verify-machineinstrs | FileCheck %s --check-prefix=ALL --check-prefix=AVX --check-prefix=AVX512 --check-prefix=AVX512F
X86 Tests: Update more isel tests with FastVariableShuffle feature Summary: Added the FastVariableShuffle feature to cases that resembled processors for which this fearure is on. For AVX2 there are processors with and w/o this fearue enable. For AVX512 only KNL does enable this feature so cases which only have +avx512f were left without the FastVariableShuffle enabled. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41851 llvm-svn: 322090
2018-01-10 00:26:06 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512f,+avx512vl,+fast-variable-shuffle -verify-machineinstrs | FileCheck %s --check-prefixes=ALL,AVX,AVX512,AVX512VL
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
;
; Half to Float
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define float @cvt_i16_to_f32(i16 %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: cvt_i16_to_f32:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl %di, %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = bitcast i16 %a0 to half
%2 = fpext half %1 to float
ret float %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x float> @cvt_4i16_to_4f32(<4 x i16> %a0) nounwind {
; AVX1-LABEL: cvt_4i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; AVX1-NEXT: vmovq %xmm0, %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: movq %rax, %rdx
; AVX1-NEXT: movswl %ax, %esi
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
; AVX1-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: shrq $48, %rdx
; AVX1-NEXT: movswl %dx, %edx
; AVX1-NEXT: vmovd %edx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: vmovd %esi, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_4i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; AVX2-NEXT: vmovq %xmm0, %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: movq %rax, %rdx
; AVX2-NEXT: movswl %ax, %esi
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
; AVX2-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: shrq $48, %rdx
; AVX2-NEXT: movswl %dx, %edx
; AVX2-NEXT: vmovd %edx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: vmovd %esi, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX2-NEXT: retq
;
; AVX512F-LABEL: cvt_4i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; AVX512F-NEXT: vmovq %xmm0, %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: movq %rax, %rdx
; AVX512F-NEXT: movswl %ax, %esi
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 $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: shrq $48, %rdx
; AVX512F-NEXT: movswl %dx, %edx
; AVX512F-NEXT: vmovd %edx, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %cx, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm2
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %esi, %xmm3
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_4i16_to_4f32:
[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
; AVX512VL: # %bb.0:
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovdw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: movq %rax, %rdx
; AVX512VL-NEXT: movswl %ax, %esi
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
; AVX512VL-NEXT: # kill: def $eax killed $eax killed $rax
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: shrl $16, %eax
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: shrq $48, %rdx
; AVX512VL-NEXT: movswl %dx, %edx
; AVX512VL-NEXT: vmovd %edx, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: vmovd %esi, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = bitcast <4 x i16> %a0 to <4 x half>
%2 = fpext <4 x half> %1 to <4 x float>
ret <4 x float> %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x float> @cvt_8i16_to_4f32(<8 x i16> %a0) nounwind {
; AVX1-LABEL: cvt_8i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vmovq %xmm0, %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: movq %rax, %rdx
; AVX1-NEXT: movswl %ax, %esi
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
; AVX1-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: shrq $48, %rdx
; AVX1-NEXT: movswl %dx, %edx
; AVX1-NEXT: vmovd %edx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: vmovd %esi, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_8i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vmovq %xmm0, %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: movq %rax, %rdx
; AVX2-NEXT: movswl %ax, %esi
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
; AVX2-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: shrq $48, %rdx
; AVX2-NEXT: movswl %dx, %edx
; AVX2-NEXT: vmovd %edx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: vmovd %esi, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX2-NEXT: retq
;
; AVX512F-LABEL: cvt_8i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovq %xmm0, %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: movq %rax, %rdx
; AVX512F-NEXT: movswl %ax, %esi
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 $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: shrq $48, %rdx
; AVX512F-NEXT: movswl %dx, %edx
; AVX512F-NEXT: vmovd %edx, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %cx, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm2
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %esi, %xmm3
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_8i16_to_4f32:
[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
; AVX512VL: # %bb.0:
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpmovzxwd {{.*#+}} xmm0 = xmm0[0],zero,xmm0[1],zero,xmm0[2],zero,xmm0[3],zero
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovdw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: movq %rax, %rdx
; AVX512VL-NEXT: movswl %ax, %esi
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
; AVX512VL-NEXT: # kill: def $eax killed $eax killed $rax
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: shrl $16, %eax
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: shrq $48, %rdx
; AVX512VL-NEXT: movswl %dx, %edx
; AVX512VL-NEXT: vmovd %edx, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: vmovd %esi, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = shufflevector <8 x i16> %a0, <8 x i16> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3>
%2 = bitcast <4 x i16> %1 to <4 x half>
%3 = fpext <4 x half> %2 to <4 x float>
ret <4 x float> %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <8 x float> @cvt_8i16_to_8f32(<8 x i16> %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: cvt_8i16_to_8f32:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vpextrq $1, %xmm0, %rdx
; ALL-NEXT: movq %rdx, %r8
; ALL-NEXT: movq %rdx, %r10
; ALL-NEXT: movswl %dx, %r9d
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
; ALL-NEXT: # kill: def $edx killed $edx killed $rdx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: shrl $16, %edx
; ALL-NEXT: shrq $32, %r8
; ALL-NEXT: shrq $48, %r10
; ALL-NEXT: vmovq %xmm0, %rdi
; ALL-NEXT: movq %rdi, %rax
; ALL-NEXT: movq %rdi, %rsi
; ALL-NEXT: movswl %di, %ecx
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
; ALL-NEXT: # kill: def $edi killed $edi killed $rdi
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: shrl $16, %edi
; ALL-NEXT: shrq $32, %rax
; ALL-NEXT: shrq $48, %rsi
; ALL-NEXT: movswl %si, %esi
; ALL-NEXT: vmovd %esi, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: cwtl
; ALL-NEXT: vmovd %eax, %xmm1
; ALL-NEXT: vcvtph2ps %xmm1, %xmm1
; ALL-NEXT: movswl %di, %eax
; ALL-NEXT: vmovd %eax, %xmm2
; ALL-NEXT: vcvtph2ps %xmm2, %xmm2
; ALL-NEXT: vmovd %ecx, %xmm3
; ALL-NEXT: vcvtph2ps %xmm3, %xmm3
; ALL-NEXT: movswl %r10w, %eax
; ALL-NEXT: vmovd %eax, %xmm4
; ALL-NEXT: vcvtph2ps %xmm4, %xmm4
; ALL-NEXT: movswl %r8w, %eax
; ALL-NEXT: vmovd %eax, %xmm5
; ALL-NEXT: vcvtph2ps %xmm5, %xmm5
; ALL-NEXT: movswl %dx, %eax
; ALL-NEXT: vmovd %eax, %xmm6
; ALL-NEXT: vcvtph2ps %xmm6, %xmm6
; ALL-NEXT: vmovd %r9d, %xmm7
; ALL-NEXT: vcvtph2ps %xmm7, %xmm7
; ALL-NEXT: vinsertps {{.*#+}} xmm6 = xmm7[0],xmm6[0],xmm7[2,3]
; ALL-NEXT: vinsertps {{.*#+}} xmm5 = xmm6[0,1],xmm5[0],xmm6[3]
; ALL-NEXT: vinsertps {{.*#+}} xmm4 = xmm5[0,1,2],xmm4[0]
; ALL-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; ALL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; ALL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; ALL-NEXT: vinsertf128 $1, %xmm4, %ymm0, %ymm0
; ALL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = bitcast <8 x i16> %a0 to <8 x half>
%2 = fpext <8 x half> %1 to <8 x float>
ret <8 x float> %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <16 x float> @cvt_16i16_to_16f32(<16 x i16> %a0) nounwind {
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-LABEL: cvt_16i16_to_16f32:
[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][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm4
; AVX1-NEXT: vmovq %xmm4, %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $48, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm8
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm9
; AVX1-NEXT: movswl %ax, %ecx
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
; AVX1-NEXT: # kill: def $eax killed $eax killed $rax
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm10
; AVX1-NEXT: vpextrq $1, %xmm4, %rax
; AVX1-NEXT: vmovd %ecx, %xmm11
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $48, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm12
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm13
; AVX1-NEXT: movswl %ax, %ecx
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
; AVX1-NEXT: # kill: def $eax killed $eax killed $rax
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm14
; AVX1-NEXT: vmovq %xmm0, %rax
; AVX1-NEXT: vmovd %ecx, %xmm15
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $48, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm2
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm3
; AVX1-NEXT: movswl %ax, %ecx
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
; AVX1-NEXT: # kill: def $eax killed $eax killed $rax
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm4
; AVX1-NEXT: vpextrq $1, %xmm0, %rax
; AVX1-NEXT: vmovd %ecx, %xmm0
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $48, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm5
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm6
; AVX1-NEXT: movl %eax, %ecx
; AVX1-NEXT: shrl $16, %ecx
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm7
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm8, %xmm8
; AVX1-NEXT: vcvtph2ps %xmm9, %xmm9
; AVX1-NEXT: vcvtph2ps %xmm10, %xmm10
; AVX1-NEXT: vcvtph2ps %xmm11, %xmm11
; AVX1-NEXT: vcvtph2ps %xmm12, %xmm12
; AVX1-NEXT: vcvtph2ps %xmm13, %xmm13
; AVX1-NEXT: vcvtph2ps %xmm14, %xmm14
; AVX1-NEXT: vcvtph2ps %xmm15, %xmm15
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX1-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX1-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0],xmm7[0],xmm1[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm6[0],xmm1[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm5[0]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0],xmm4[0],xmm0[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1],xmm3[0],xmm0[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1,2],xmm2[0]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm15[0],xmm14[0],xmm15[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm13[0],xmm1[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm12[0]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm11[0],xmm10[0],xmm11[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_16i16_to_16f32:
[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][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: vextracti128 $1, %ymm0, %xmm4
; AVX2-NEXT: vmovq %xmm4, %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $48, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm8
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm9
; AVX2-NEXT: movswl %ax, %ecx
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
; AVX2-NEXT: # kill: def $eax killed $eax killed $rax
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm10
; AVX2-NEXT: vpextrq $1, %xmm4, %rax
; AVX2-NEXT: vmovd %ecx, %xmm11
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $48, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm12
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm13
; AVX2-NEXT: movswl %ax, %ecx
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
; AVX2-NEXT: # kill: def $eax killed $eax killed $rax
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm14
; AVX2-NEXT: vmovq %xmm0, %rax
; AVX2-NEXT: vmovd %ecx, %xmm15
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $48, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm2
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm3
; AVX2-NEXT: movswl %ax, %ecx
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
; AVX2-NEXT: # kill: def $eax killed $eax killed $rax
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm4
; AVX2-NEXT: vpextrq $1, %xmm0, %rax
; AVX2-NEXT: vmovd %ecx, %xmm0
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $48, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm5
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm6
; AVX2-NEXT: movl %eax, %ecx
; AVX2-NEXT: shrl $16, %ecx
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm7
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm8, %xmm8
; AVX2-NEXT: vcvtph2ps %xmm9, %xmm9
; AVX2-NEXT: vcvtph2ps %xmm10, %xmm10
; AVX2-NEXT: vcvtph2ps %xmm11, %xmm11
; AVX2-NEXT: vcvtph2ps %xmm12, %xmm12
; AVX2-NEXT: vcvtph2ps %xmm13, %xmm13
; AVX2-NEXT: vcvtph2ps %xmm14, %xmm14
; AVX2-NEXT: vcvtph2ps %xmm15, %xmm15
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX2-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX2-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0],xmm7[0],xmm1[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm6[0],xmm1[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm5[0]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0],xmm4[0],xmm0[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1],xmm3[0],xmm0[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1,2],xmm2[0]
; AVX2-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm15[0],xmm14[0],xmm15[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm13[0],xmm1[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm12[0]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm11[0],xmm10[0],xmm11[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
; AVX2-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
; AVX2-NEXT: retq
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-LABEL: cvt_16i16_to_16f32:
[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 FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vextracti128 $1, %ymm0, %xmm10
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovq %xmm0, %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $48, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm8
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm9
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %ax, %ecx
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 $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: cwtl
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm11
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vpextrq $1, %xmm0, %rax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm12
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $48, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm13
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm14
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %ax, %ecx
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 $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: cwtl
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm15
; AVX512F-NEXT: vmovq %xmm10, %rax
; AVX512F-NEXT: vmovd %ecx, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $48, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %ax, %ecx
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 $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: cwtl
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm4
; AVX512F-NEXT: vpextrq $1, %xmm10, %rax
; AVX512F-NEXT: vmovd %ecx, %xmm10
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $48, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm5
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm6
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movl %eax, %ecx
; AVX512F-NEXT: shrl $16, %ecx
; AVX512F-NEXT: movswl %cx, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm7
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm8, %xmm8
; AVX512F-NEXT: vcvtph2ps %xmm9, %xmm9
; AVX512F-NEXT: vcvtph2ps %xmm11, %xmm11
; AVX512F-NEXT: vcvtph2ps %xmm12, %xmm12
; AVX512F-NEXT: vcvtph2ps %xmm13, %xmm13
; AVX512F-NEXT: vcvtph2ps %xmm14, %xmm14
; AVX512F-NEXT: vcvtph2ps %xmm15, %xmm15
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512F-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX512F-NEXT: vcvtph2ps %xmm10, %xmm10
; AVX512F-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX512F-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX512F-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0],xmm7[0],xmm0[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1],xmm6[0],xmm0[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1,2],xmm5[0]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm4 = xmm10[0],xmm4[0],xmm10[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm4[0,1],xmm1[0],xmm4[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm3[0]
; AVX512F-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0],xmm15[0],xmm2[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm14[0],xmm1[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm13[0]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm12[0],xmm11[0],xmm12[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
; AVX512F-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
; AVX512F-NEXT: vinsertf64x4 $1, %ymm0, %zmm1, %zmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_16i16_to_16f32:
[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
; AVX512VL: # %bb.0:
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vextracti128 $1, %ymm0, %xmm10
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vmovq %xmm0, %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: shrq $48, %rcx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm8
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm9
; AVX512VL-NEXT: movswl %ax, %ecx
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
; AVX512VL-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shrl $16, %eax
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm11
; AVX512VL-NEXT: vpextrq $1, %xmm0, %rax
; AVX512VL-NEXT: vmovd %ecx, %xmm12
; AVX512VL-NEXT: movq %rax, %rcx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shrq $48, %rcx
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm13
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm14
; AVX512VL-NEXT: movswl %ax, %ecx
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
; AVX512VL-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shrl $16, %eax
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm15
; AVX512VL-NEXT: vmovq %xmm10, %rax
; AVX512VL-NEXT: vmovd %ecx, %xmm16
; AVX512VL-NEXT: movq %rax, %rcx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shrq $48, %rcx
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm17
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm18
; AVX512VL-NEXT: movswl %ax, %ecx
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
; AVX512VL-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shrl $16, %eax
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm19
; AVX512VL-NEXT: vpextrq $1, %xmm10, %rax
; AVX512VL-NEXT: vmovd %ecx, %xmm10
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: shrq $48, %rcx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm20
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm21
; AVX512VL-NEXT: movl %eax, %ecx
; AVX512VL-NEXT: shrl $16, %ecx
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm22
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm8, %xmm8
; AVX512VL-NEXT: vcvtph2ps %xmm9, %xmm9
; AVX512VL-NEXT: vcvtph2ps %xmm11, %xmm11
; AVX512VL-NEXT: vcvtph2ps %xmm12, %xmm12
; AVX512VL-NEXT: vcvtph2ps %xmm13, %xmm13
; AVX512VL-NEXT: vcvtph2ps %xmm14, %xmm14
; AVX512VL-NEXT: vcvtph2ps %xmm15, %xmm15
; AVX512VL-NEXT: vcvtph2ps %xmm16, %xmm16
; AVX512VL-NEXT: vcvtph2ps %xmm17, %xmm4
; AVX512VL-NEXT: vcvtph2ps %xmm18, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm19, %xmm5
; AVX512VL-NEXT: vcvtph2ps %xmm10, %xmm7
; AVX512VL-NEXT: vcvtph2ps %xmm20, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm21, %xmm6
; AVX512VL-NEXT: vcvtph2ps %xmm22, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0],xmm1[0],xmm2[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm6[0],xmm1[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm3[0]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm7[0],xmm5[0],xmm7[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm0 = xmm2[0,1],xmm0[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm0 = xmm0[0,1,2],xmm4[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm16[0],xmm15[0],xmm16[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm14[0],xmm1[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm13[0]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm12[0],xmm11[0],xmm12[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vinsertf64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512VL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = bitcast <16 x i16> %a0 to <16 x half>
%2 = fpext <16 x half> %1 to <16 x float>
ret <16 x float> %2
}
;
; Half to Float (Load)
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define float @load_cvt_i16_to_f32(i16* %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: load_cvt_i16_to_f32:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl (%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = load i16, i16* %a0
%2 = bitcast i16 %1 to half
%3 = fpext half %2 to float
ret float %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x float> @load_cvt_4i16_to_4f32(<4 x i16>* %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: load_cvt_4i16_to_4f32:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl 6(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: movswl 4(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm1
; ALL-NEXT: vcvtph2ps %xmm1, %xmm1
; ALL-NEXT: movswl (%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm2
; ALL-NEXT: vcvtph2ps %xmm2, %xmm2
; ALL-NEXT: movswl 2(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm3
; ALL-NEXT: vcvtph2ps %xmm3, %xmm3
; ALL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0],xmm3[0],xmm2[2,3]
; ALL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; ALL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; ALL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = load <4 x i16>, <4 x i16>* %a0
%2 = bitcast <4 x i16> %1 to <4 x half>
%3 = fpext <4 x half> %2 to <4 x float>
ret <4 x float> %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x float> @load_cvt_8i16_to_4f32(<8 x i16>* %a0) nounwind {
; AVX1-LABEL: load_cvt_8i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: movq (%rdi), %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: movq %rax, %rdx
; AVX1-NEXT: movswl %ax, %esi
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
; AVX1-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: shrq $48, %rdx
; AVX1-NEXT: movswl %dx, %edx
; AVX1-NEXT: vmovd %edx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: vmovd %esi, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX1-NEXT: retq
;
; AVX2-LABEL: load_cvt_8i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: movq (%rdi), %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: movq %rax, %rdx
; AVX2-NEXT: movswl %ax, %esi
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
; AVX2-NEXT: # kill: def $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: shrq $48, %rdx
; AVX2-NEXT: movswl %dx, %edx
; AVX2-NEXT: vmovd %edx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: vmovd %esi, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX2-NEXT: retq
;
; AVX512F-LABEL: load_cvt_8i16_to_4f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq (%rdi), %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: movq %rax, %rdx
; AVX512F-NEXT: movswl %ax, %esi
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 $eax killed $eax killed $rax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: shrq $48, %rdx
; AVX512F-NEXT: movswl %dx, %edx
; AVX512F-NEXT: vmovd %edx, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %cx, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm2
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %esi, %xmm3
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: load_cvt_8i16_to_4f32:
[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
; AVX512VL: # %bb.0:
[AVX-512] Port 128 and 256-bit memory->register sign/zero extend patterns from SSE file. Also add a minimal set for 512-bit. llvm-svn: 283704
2016-10-10 07:08:39 +08:00
; AVX512VL-NEXT: vpmovzxwd {{.*#+}} xmm0 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovdw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: movq %rax, %rdx
; AVX512VL-NEXT: movswl %ax, %esi
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
; AVX512VL-NEXT: # kill: def $eax killed $eax killed $rax
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: shrl $16, %eax
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: shrq $48, %rdx
; AVX512VL-NEXT: movswl %dx, %edx
; AVX512VL-NEXT: vmovd %edx, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: vmovd %esi, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = load <8 x i16>, <8 x i16>* %a0
%2 = shufflevector <8 x i16> %1, <8 x i16> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3>
%3 = bitcast <4 x i16> %2 to <4 x half>
%4 = fpext <4 x half> %3 to <4 x float>
ret <4 x float> %4
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <8 x float> @load_cvt_8i16_to_8f32(<8 x i16>* %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: load_cvt_8i16_to_8f32:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl 6(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: movswl 4(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm1
; ALL-NEXT: vcvtph2ps %xmm1, %xmm1
; ALL-NEXT: movswl (%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm2
; ALL-NEXT: vcvtph2ps %xmm2, %xmm2
; ALL-NEXT: movswl 2(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm3
; ALL-NEXT: vcvtph2ps %xmm3, %xmm3
; ALL-NEXT: movswl 14(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm4
; ALL-NEXT: vcvtph2ps %xmm4, %xmm4
; ALL-NEXT: movswl 12(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm5
; ALL-NEXT: vcvtph2ps %xmm5, %xmm5
; ALL-NEXT: movswl 8(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm6
; ALL-NEXT: vcvtph2ps %xmm6, %xmm6
; ALL-NEXT: movswl 10(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm7
; ALL-NEXT: vcvtph2ps %xmm7, %xmm7
; ALL-NEXT: vinsertps {{.*#+}} xmm6 = xmm6[0],xmm7[0],xmm6[2,3]
; ALL-NEXT: vinsertps {{.*#+}} xmm5 = xmm6[0,1],xmm5[0],xmm6[3]
; ALL-NEXT: vinsertps {{.*#+}} xmm4 = xmm5[0,1,2],xmm4[0]
; ALL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0],xmm3[0],xmm2[2,3]
; ALL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; ALL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; ALL-NEXT: vinsertf128 $1, %xmm4, %ymm0, %ymm0
; ALL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = load <8 x i16>, <8 x i16>* %a0
%2 = bitcast <8 x i16> %1 to <8 x half>
%3 = fpext <8 x half> %2 to <8 x float>
ret <8 x float> %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <16 x float> @load_cvt_16i16_to_16f32(<16 x i16>* %a0) nounwind {
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-LABEL: load_cvt_16i16_to_16f32:
[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][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: movswl 22(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm8
; AVX1-NEXT: movswl 20(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm9
; AVX1-NEXT: movswl 16(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm10
; AVX1-NEXT: movswl 18(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm11
; AVX1-NEXT: movswl 30(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm12
; AVX1-NEXT: movswl 28(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm13
; AVX1-NEXT: movswl 24(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm14
; AVX1-NEXT: movswl 26(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm15
; AVX1-NEXT: movswl 6(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: movswl 4(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: movswl (%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: movswl 2(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm4
; AVX1-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX1-NEXT: movswl 14(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm5
; AVX1-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX1-NEXT: movswl 12(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm6
; AVX1-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX1-NEXT: movswl 8(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm7
; AVX1-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX1-NEXT: movswl 10(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm7[0],xmm1[0],xmm7[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm6[0],xmm1[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm5[0]
; AVX1-NEXT: vinsertps {{.*#+}} xmm3 = xmm3[0],xmm4[0],xmm3[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0,1],xmm2[0],xmm3[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm0 = xmm2[0,1,2],xmm0[0]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm14[0],xmm15[0],xmm14[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm13[0],xmm1[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm12[0]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm10[0],xmm11[0],xmm10[2,3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX1-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
; AVX1-NEXT: retq
;
; AVX2-LABEL: load_cvt_16i16_to_16f32:
[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][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: movswl 22(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm8
; AVX2-NEXT: movswl 20(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm9
; AVX2-NEXT: movswl 16(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm10
; AVX2-NEXT: movswl 18(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm11
; AVX2-NEXT: movswl 30(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm12
; AVX2-NEXT: movswl 28(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm13
; AVX2-NEXT: movswl 24(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm14
; AVX2-NEXT: movswl 26(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm15
; AVX2-NEXT: movswl 6(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: movswl 4(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: movswl (%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: movswl 2(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm4
; AVX2-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX2-NEXT: movswl 14(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm5
; AVX2-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX2-NEXT: movswl 12(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm6
; AVX2-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX2-NEXT: movswl 8(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm7
; AVX2-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX2-NEXT: movswl 10(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm7[0],xmm1[0],xmm7[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm6[0],xmm1[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm5[0]
; AVX2-NEXT: vinsertps {{.*#+}} xmm3 = xmm3[0],xmm4[0],xmm3[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm3[0,1],xmm2[0],xmm3[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm0 = xmm2[0,1,2],xmm0[0]
; AVX2-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm14[0],xmm15[0],xmm14[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm13[0],xmm1[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm12[0]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm10[0],xmm11[0],xmm10[2,3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX2-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
; AVX2-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
; AVX2-NEXT: retq
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-LABEL: load_cvt_16i16_to_16f32:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 6(%rdi), %eax
; AVX512F-NEXT: vmovd %eax, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm8
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 4(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm9
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl (%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm10
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 2(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm11
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 14(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm12
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 12(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm13
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 8(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm14
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 10(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm15
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 22(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm0
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 20(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm1
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 16(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm2
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 18(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm3
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 30(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm4
; AVX512F-NEXT: vcvtph2ps %xmm4, %xmm4
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 28(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm5
; AVX512F-NEXT: vcvtph2ps %xmm5, %xmm5
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 24(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm6
; AVX512F-NEXT: vcvtph2ps %xmm6, %xmm6
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl 26(%rdi), %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vmovd %eax, %xmm7
; AVX512F-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX512F-NEXT: vinsertps {{.*#+}} xmm6 = xmm6[0],xmm7[0],xmm6[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm5 = xmm6[0,1],xmm5[0],xmm6[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm4 = xmm5[0,1,2],xmm4[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0],xmm3[0],xmm2[2,3]
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
; AVX512F-NEXT: vinsertf128 $1, %xmm4, %ymm0, %ymm0
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm14[0],xmm15[0],xmm14[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm13[0],xmm1[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm12[0]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm10[0],xmm11[0],xmm10[2,3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX512F-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
[AVX-512] Fix execution domain for EVEX encoded VINSERTPS. llvm-svn: 283692
2016-10-09 14:41:47 +08:00
; AVX512F-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertf64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: load_cvt_16i16_to_16f32:
[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
; AVX512VL: # %bb.0:
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: movswl 6(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm8
; AVX512VL-NEXT: movswl 4(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm9
; AVX512VL-NEXT: movswl (%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm10
; AVX512VL-NEXT: movswl 2(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm11
; AVX512VL-NEXT: movswl 14(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm4
; AVX512VL-NEXT: vcvtph2ps %xmm4, %xmm12
; AVX512VL-NEXT: movswl 12(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm5
; AVX512VL-NEXT: vcvtph2ps %xmm5, %xmm13
; AVX512VL-NEXT: movswl 8(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm6
; AVX512VL-NEXT: vcvtph2ps %xmm6, %xmm14
; AVX512VL-NEXT: movswl 10(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm7
; AVX512VL-NEXT: vcvtph2ps %xmm7, %xmm15
; AVX512VL-NEXT: movswl 22(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: movswl 20(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: movswl 16(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: movswl 18(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: movswl 30(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm4
; AVX512VL-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX512VL-NEXT: movswl 28(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm5
; AVX512VL-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX512VL-NEXT: movswl 24(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm6
; AVX512VL-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX512VL-NEXT: movswl 26(%rdi), %eax
; AVX512VL-NEXT: vmovd %eax, %xmm7
; AVX512VL-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm6 = xmm6[0],xmm7[0],xmm6[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm5 = xmm6[0,1],xmm5[0],xmm6[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm4 = xmm5[0,1,2],xmm4[0]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0],xmm3[0],xmm2[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm2[0,1],xmm1[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm0 = xmm1[0,1,2],xmm0[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm4, %ymm0, %ymm0
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm14[0],xmm15[0],xmm14[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1],xmm13[0],xmm1[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm1 = xmm1[0,1,2],xmm12[0]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm10[0],xmm11[0],xmm10[2,3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1],xmm9[0],xmm2[3]
; AVX512VL-NEXT: vinsertps {{.*#+}} xmm2 = xmm2[0,1,2],xmm8[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm1, %ymm2, %ymm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vinsertf64x4 $1, %ymm0, %zmm1, %zmm0
; AVX512VL-NEXT: retq
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%1 = load <16 x i16>, <16 x i16>* %a0
%2 = bitcast <16 x i16> %1 to <16 x half>
%3 = fpext <16 x half> %2 to <16 x float>
ret <16 x float> %3
}
;
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; Half to Double
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define double @cvt_i16_to_f64(i16 %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: cvt_i16_to_f64:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl %di, %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = bitcast i16 %a0 to half
%2 = fpext half %1 to double
ret double %2
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <2 x double> @cvt_2i16_to_2f64(<2 x i16> %a0) nounwind {
; AVX1-LABEL: cvt_2i16_to_2f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: movswl %ax, %ecx
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: vmovd %ecx, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: retq
;
X86 Tests: Update more isel tests with FastVariableShuffle feature Summary: Added the FastVariableShuffle feature to cases that resembled processors for which this fearure is on. For AVX2 there are processors with and w/o this fearue enable. For AVX512 only KNL does enable this feature so cases which only have +avx512f were left without the FastVariableShuffle enabled. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41851 llvm-svn: 322090
2018-01-10 00:26:06 +08:00
; AVX2-SLOW-LABEL: cvt_2i16_to_2f64:
; AVX2-SLOW: # %bb.0:
; AVX2-SLOW-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; AVX2-SLOW-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX2-SLOW-NEXT: vmovd %xmm0, %eax
; AVX2-SLOW-NEXT: movswl %ax, %ecx
; AVX2-SLOW-NEXT: shrl $16, %eax
; AVX2-SLOW-NEXT: cwtl
; AVX2-SLOW-NEXT: vmovd %eax, %xmm0
; AVX2-SLOW-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-SLOW-NEXT: vmovd %ecx, %xmm1
; AVX2-SLOW-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-SLOW-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX2-SLOW-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; AVX2-SLOW-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX2-SLOW-NEXT: retq
;
; AVX2-FAST-LABEL: cvt_2i16_to_2f64:
; AVX2-FAST: # %bb.0:
; AVX2-FAST-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,8,9,8,9,10,11,8,9,10,11,12,13,14,15]
; AVX2-FAST-NEXT: vmovd %xmm0, %eax
; AVX2-FAST-NEXT: movswl %ax, %ecx
; AVX2-FAST-NEXT: shrl $16, %eax
; AVX2-FAST-NEXT: cwtl
; AVX2-FAST-NEXT: vmovd %eax, %xmm0
; AVX2-FAST-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-FAST-NEXT: vmovd %ecx, %xmm1
; AVX2-FAST-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-FAST-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX2-FAST-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; AVX2-FAST-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX2-FAST-NEXT: retq
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
;
; AVX512F-LABEL: cvt_2i16_to_2f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
; AVX512F-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX512F-NEXT: vmovd %xmm0, %eax
; AVX512F-NEXT: movswl %ax, %ecx
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_2i16_to_2f64:
[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
; AVX512VL: # %bb.0:
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovqw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movl -{{[0-9]+}}(%rsp), %eax
; AVX512VL-NEXT: movswl %ax, %ecx
; AVX512VL-NEXT: shrl $16, %eax
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %ecx, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = bitcast <2 x i16> %a0 to <2 x half>
%2 = fpext <2 x half> %1 to <2 x double>
ret <2 x double> %2
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x double> @cvt_4i16_to_4f64(<4 x i16> %a0) nounwind {
; AVX1-LABEL: cvt_4i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; AVX1-NEXT: vmovq %xmm0, %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: movl %eax, %edx
; AVX1-NEXT: movswl %ax, %esi
; AVX1-NEXT: shrq $48, %rax
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: shrl $16, %edx
; AVX1-NEXT: movswl %dx, %edx
; AVX1-NEXT: vmovd %edx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: vmovd %esi, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX1-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_4i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; AVX2-NEXT: vmovq %xmm0, %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: movl %eax, %edx
; AVX2-NEXT: movswl %ax, %esi
; AVX2-NEXT: shrq $48, %rax
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: shrl $16, %edx
; AVX2-NEXT: movswl %dx, %edx
; AVX2-NEXT: vmovd %edx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: vmovd %esi, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX2-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX2-NEXT: retq
;
; AVX512F-LABEL: cvt_4i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,8,9,12,13,8,9,12,13,12,13,14,15]
; AVX512F-NEXT: vmovq %xmm0, %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: movl %eax, %edx
; AVX512F-NEXT: movswl %ax, %esi
; AVX512F-NEXT: shrq $48, %rax
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: shrl $16, %edx
; AVX512F-NEXT: movswl %dx, %edx
; AVX512F-NEXT: vmovd %edx, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %esi, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %cx, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm2
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm3
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512F-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_4i16_to_4f64:
[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
; AVX512VL: # %bb.0:
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovdw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: movl %eax, %edx
; AVX512VL-NEXT: movswl %ax, %esi
; AVX512VL-NEXT: shrq $48, %rax
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: shrl $16, %edx
; AVX512VL-NEXT: movswl %dx, %edx
; AVX512VL-NEXT: vmovd %edx, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %esi, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512VL-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
%1 = bitcast <4 x i16> %a0 to <4 x half>
%2 = fpext <4 x half> %1 to <4 x double>
ret <4 x double> %2
}
define <2 x double> @cvt_8i16_to_2f64(<8 x i16> %a0) nounwind {
; AVX1-LABEL: cvt_8i16_to_2f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: movswl %ax, %ecx
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: vmovd %ecx, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_8i16_to_2f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: movswl %ax, %ecx
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: vmovd %ecx, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: retq
;
; AVX512F-LABEL: cvt_8i16_to_2f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm0, %eax
; AVX512F-NEXT: movswl %ax, %ecx
; AVX512F-NEXT: shrl $16, %eax
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %ecx, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_8i16_to_2f64:
[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
; AVX512VL: # %bb.0:
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpmovzxwq {{.*#+}} xmm0 = xmm0[0],zero,zero,zero,xmm0[1],zero,zero,zero
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovqw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movl -{{[0-9]+}}(%rsp), %eax
; AVX512VL-NEXT: movswl %ax, %ecx
; AVX512VL-NEXT: shrl $16, %eax
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %ecx, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
%1 = shufflevector <8 x i16> %a0, <8 x i16> undef, <2 x i32> <i32 0, i32 1>
%2 = bitcast <2 x i16> %1 to <2 x half>
%3 = fpext <2 x half> %2 to <2 x double>
ret <2 x double> %3
}
define <4 x double> @cvt_8i16_to_4f64(<8 x i16> %a0) nounwind {
; AVX1-LABEL: cvt_8i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vmovq %xmm0, %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: movl %eax, %edx
; AVX1-NEXT: movswl %ax, %esi
; AVX1-NEXT: shrq $48, %rax
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: shrl $16, %edx
; AVX1-NEXT: movswl %dx, %edx
; AVX1-NEXT: vmovd %edx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: vmovd %esi, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX1-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_8i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vmovq %xmm0, %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: movl %eax, %edx
; AVX2-NEXT: movswl %ax, %esi
; AVX2-NEXT: shrq $48, %rax
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: shrl $16, %edx
; AVX2-NEXT: movswl %dx, %edx
; AVX2-NEXT: vmovd %edx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: vmovd %esi, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX2-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX2-NEXT: retq
;
; AVX512F-LABEL: cvt_8i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovq %xmm0, %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: movl %eax, %edx
; AVX512F-NEXT: movswl %ax, %esi
; AVX512F-NEXT: shrq $48, %rax
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: shrl $16, %edx
; AVX512F-NEXT: movswl %dx, %edx
; AVX512F-NEXT: vmovd %edx, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %esi, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %cx, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm2
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm3
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512F-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: cvt_8i16_to_4f64:
[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
; AVX512VL: # %bb.0:
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpmovzxwd {{.*#+}} xmm0 = xmm0[0],zero,xmm0[1],zero,xmm0[2],zero,xmm0[3],zero
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovdw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: movl %eax, %edx
; AVX512VL-NEXT: movswl %ax, %esi
; AVX512VL-NEXT: shrq $48, %rax
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: shrl $16, %edx
; AVX512VL-NEXT: movswl %dx, %edx
; AVX512VL-NEXT: vmovd %edx, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %esi, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512VL-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = shufflevector <8 x i16> %a0, <8 x i16> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3>
%2 = bitcast <4 x i16> %1 to <4 x half>
%3 = fpext <4 x half> %2 to <4 x double>
ret <4 x double> %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <8 x double> @cvt_8i16_to_8f64(<8 x i16> %a0) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: cvt_8i16_to_8f64:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vmovq %xmm0, %rdx
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: movq %rdx, %r9
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %edx, %r10d
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: movswl %dx, %r8d
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shrq $48, %rdx
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: shrq $32, %r9
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shrl $16, %r10d
; AVX1-NEXT: vpextrq $1, %xmm0, %rdi
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: movq %rdi, %rsi
; AVX1-NEXT: movl %edi, %eax
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movswl %di, %ecx
; AVX1-NEXT: shrq $48, %rdi
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: shrq $32, %rsi
; AVX1-NEXT: shrl $16, %eax
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm1
; AVX1-NEXT: vmovd %ecx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm2
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: movswl %si, %eax
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm3
; AVX1-NEXT: movswl %di, %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm4
; AVX1-NEXT: movswl %r10w, %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: vmovd %r8d, %xmm5
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtph2ps %xmm5, %xmm5
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX1-NEXT: movswl %r9w, %eax
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vmovd %eax, %xmm6
; AVX1-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX1-NEXT: movswl %dx, %eax
; AVX1-NEXT: vmovd %eax, %xmm7
; AVX1-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX1-NEXT: vcvtss2sd %xmm7, %xmm7, %xmm7
; AVX1-NEXT: vcvtss2sd %xmm6, %xmm6, %xmm6
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm6 = xmm6[0],xmm7[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtss2sd %xmm5, %xmm5, %xmm5
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm5[0],xmm0[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm6, %ymm0, %ymm0
; AVX1-NEXT: vcvtss2sd %xmm4, %xmm4, %xmm4
; AVX1-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm3 = xmm3[0],xmm4[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm1 = xmm2[0],xmm1[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm3, %ymm1, %ymm1
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: retq
;
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-LABEL: cvt_8i16_to_8f64:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vmovq %xmm0, %rdx
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: movq %rdx, %r9
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %edx, %r10d
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: movswl %dx, %r8d
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shrq $48, %rdx
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: shrq $32, %r9
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shrl $16, %r10d
; AVX2-NEXT: vpextrq $1, %xmm0, %rdi
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: movq %rdi, %rsi
; AVX2-NEXT: movl %edi, %eax
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movswl %di, %ecx
; AVX2-NEXT: shrq $48, %rdi
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: shrq $32, %rsi
; AVX2-NEXT: shrl $16, %eax
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm1
; AVX2-NEXT: vmovd %ecx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm2
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: movswl %si, %eax
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm3
; AVX2-NEXT: movswl %di, %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm4
; AVX2-NEXT: movswl %r10w, %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: vmovd %r8d, %xmm5
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtph2ps %xmm5, %xmm5
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX2-NEXT: movswl %r9w, %eax
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vmovd %eax, %xmm6
; AVX2-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX2-NEXT: movswl %dx, %eax
; AVX2-NEXT: vmovd %eax, %xmm7
; AVX2-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX2-NEXT: vcvtss2sd %xmm7, %xmm7, %xmm7
; AVX2-NEXT: vcvtss2sd %xmm6, %xmm6, %xmm6
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm6 = xmm6[0],xmm7[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtss2sd %xmm5, %xmm5, %xmm5
; AVX2-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm0 = xmm5[0],xmm0[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm6, %ymm0, %ymm0
; AVX2-NEXT: vcvtss2sd %xmm4, %xmm4, %xmm4
; AVX2-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm3 = xmm3[0],xmm4[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; AVX2-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm1 = xmm2[0],xmm1[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm3, %ymm1, %ymm1
; AVX2-NEXT: retq
;
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-LABEL: cvt_8i16_to_8f64:
[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] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vpextrq $1, %xmm0, %rdx
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: movq %rdx, %r9
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: movl %edx, %r10d
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: movswl %dx, %r8d
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: shrq $48, %rdx
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: shrq $32, %r9
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: shrl $16, %r10d
; AVX512-NEXT: vmovq %xmm0, %rdi
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: movq %rdi, %rsi
; AVX512-NEXT: movl %edi, %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: movswl %di, %ecx
; AVX512-NEXT: shrq $48, %rdi
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: shrq $32, %rsi
; AVX512-NEXT: shrl $16, %eax
; AVX512-NEXT: cwtl
; AVX512-NEXT: vmovd %eax, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512-NEXT: vmovd %ecx, %xmm1
; AVX512-NEXT: vcvtph2ps %xmm1, %xmm1
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: movswl %si, %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vmovd %eax, %xmm2
; AVX512-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512-NEXT: movswl %di, %eax
; AVX512-NEXT: vmovd %eax, %xmm3
; AVX512-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512-NEXT: movswl %r10w, %eax
; AVX512-NEXT: vmovd %eax, %xmm4
; AVX512-NEXT: vcvtph2ps %xmm4, %xmm4
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: vmovd %r8d, %xmm5
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vcvtph2ps %xmm5, %xmm5
[X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
2017-11-07 12:44:22 +08:00
; AVX512-NEXT: movswl %r9w, %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vmovd %eax, %xmm6
; AVX512-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX512-NEXT: movswl %dx, %eax
; AVX512-NEXT: vmovd %eax, %xmm7
; AVX512-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX512-NEXT: vcvtss2sd %xmm7, %xmm7, %xmm7
; AVX512-NEXT: vcvtss2sd %xmm6, %xmm6, %xmm6
; AVX512-NEXT: vmovlhps {{.*#+}} xmm6 = xmm6[0],xmm7[0]
; AVX512-NEXT: vcvtss2sd %xmm5, %xmm5, %xmm5
; AVX512-NEXT: vcvtss2sd %xmm4, %xmm4, %xmm4
; AVX512-NEXT: vmovlhps {{.*#+}} xmm4 = xmm5[0],xmm4[0]
; AVX512-NEXT: vinsertf128 $1, %xmm6, %ymm4, %ymm4
; AVX512-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; AVX512-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; AVX512-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; AVX512-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX512-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX512-NEXT: vinsertf64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = bitcast <8 x i16> %a0 to <8 x half>
%2 = fpext <8 x half> %1 to <8 x double>
ret <8 x double> %2
}
;
; Half to Double (Load)
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define double @load_cvt_i16_to_f64(i16* %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: load_cvt_i16_to_f64:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl (%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = load i16, i16* %a0
%2 = bitcast i16 %1 to half
%3 = fpext half %2 to double
ret double %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <2 x double> @load_cvt_2i16_to_2f64(<2 x i16>* %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: load_cvt_2i16_to_2f64:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl (%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: movswl 2(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm1
; ALL-NEXT: vcvtph2ps %xmm1, %xmm1
; ALL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; ALL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; ALL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; ALL-NEXT: retq
[AVX-512] Use 512-bit vcvtps2ph/vcvtph2ps to implement fp_to_f16/f16_to_fp when F16C and VLX are not supported. Fixes PR23941. llvm-svn: 281958
2016-09-20 13:44:47 +08:00
%1 = load <2 x i16>, <2 x i16>* %a0
%2 = bitcast <2 x i16> %1 to <2 x half>
%3 = fpext <2 x half> %2 to <2 x double>
ret <2 x double> %3
}
define <4 x double> @load_cvt_4i16_to_4f64(<4 x i16>* %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: load_cvt_4i16_to_4f64:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: movswl (%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: vcvtph2ps %xmm0, %xmm0
; ALL-NEXT: movswl 2(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm1
; ALL-NEXT: vcvtph2ps %xmm1, %xmm1
; ALL-NEXT: movswl 4(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm2
; ALL-NEXT: vcvtph2ps %xmm2, %xmm2
; ALL-NEXT: movswl 6(%rdi), %eax
; ALL-NEXT: vmovd %eax, %xmm3
; ALL-NEXT: vcvtph2ps %xmm3, %xmm3
; ALL-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; ALL-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; ALL-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; ALL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; ALL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; ALL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; ALL-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = load <4 x i16>, <4 x i16>* %a0
%2 = bitcast <4 x i16> %1 to <4 x half>
%3 = fpext <4 x half> %2 to <4 x double>
ret <4 x double> %3
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x double> @load_cvt_8i16_to_4f64(<8 x i16>* %a0) nounwind {
; AVX1-LABEL: load_cvt_8i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: movq (%rdi), %rax
; AVX1-NEXT: movq %rax, %rcx
; AVX1-NEXT: movl %eax, %edx
; AVX1-NEXT: movswl %ax, %esi
; AVX1-NEXT: shrq $48, %rax
; AVX1-NEXT: shrq $32, %rcx
; AVX1-NEXT: shrl $16, %edx
; AVX1-NEXT: movswl %dx, %edx
; AVX1-NEXT: vmovd %edx, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: vmovd %esi, %xmm1
; AVX1-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX1-NEXT: movswl %cx, %ecx
; AVX1-NEXT: vmovd %ecx, %xmm2
; AVX1-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX1-NEXT: cwtl
; AVX1-NEXT: vmovd %eax, %xmm3
; AVX1-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX1-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX1-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: load_cvt_8i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: movq (%rdi), %rax
; AVX2-NEXT: movq %rax, %rcx
; AVX2-NEXT: movl %eax, %edx
; AVX2-NEXT: movswl %ax, %esi
; AVX2-NEXT: shrq $48, %rax
; AVX2-NEXT: shrq $32, %rcx
; AVX2-NEXT: shrl $16, %edx
; AVX2-NEXT: movswl %dx, %edx
; AVX2-NEXT: vmovd %edx, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: vmovd %esi, %xmm1
; AVX2-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX2-NEXT: movswl %cx, %ecx
; AVX2-NEXT: vmovd %ecx, %xmm2
; AVX2-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX2-NEXT: cwtl
; AVX2-NEXT: vmovd %eax, %xmm3
; AVX2-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX2-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX2-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX2-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX2-NEXT: retq
;
; AVX512F-LABEL: load_cvt_8i16_to_4f64:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movq (%rdi), %rax
; AVX512F-NEXT: movq %rax, %rcx
; AVX512F-NEXT: movl %eax, %edx
; AVX512F-NEXT: movswl %ax, %esi
; AVX512F-NEXT: shrq $48, %rax
; AVX512F-NEXT: shrq $32, %rcx
; AVX512F-NEXT: shrl $16, %edx
; AVX512F-NEXT: movswl %dx, %edx
; AVX512F-NEXT: vmovd %edx, %xmm0
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %esi, %xmm1
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movswl %cx, %ecx
; AVX512F-NEXT: vmovd %ecx, %xmm2
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm2, %xmm2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: cwtl
; AVX512F-NEXT: vmovd %eax, %xmm3
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtph2ps %xmm3, %xmm3
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512F-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512F-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512F-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX512F-NEXT: retq
;
; AVX512VL-LABEL: load_cvt_8i16_to_4f64:
[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
; AVX512VL: # %bb.0:
[AVX-512] Port 128 and 256-bit memory->register sign/zero extend patterns from SSE file. Also add a minimal set for 512-bit. llvm-svn: 283704
2016-10-10 07:08:39 +08:00
; AVX512VL-NEXT: vpmovzxwd {{.*#+}} xmm0 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vpmovdw %xmm0, -{{[0-9]+}}(%rsp)
; AVX512VL-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; AVX512VL-NEXT: movq %rax, %rcx
; AVX512VL-NEXT: movl %eax, %edx
; AVX512VL-NEXT: movswl %ax, %esi
; AVX512VL-NEXT: shrq $48, %rax
; AVX512VL-NEXT: shrq $32, %rcx
; AVX512VL-NEXT: shrl $16, %edx
; AVX512VL-NEXT: movswl %dx, %edx
; AVX512VL-NEXT: vmovd %edx, %xmm0
; AVX512VL-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %esi, %xmm1
; AVX512VL-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512VL-NEXT: movswl %cx, %ecx
; AVX512VL-NEXT: vmovd %ecx, %xmm2
; AVX512VL-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512VL-NEXT: cwtl
; AVX512VL-NEXT: vmovd %eax, %xmm3
; AVX512VL-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512VL-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512VL-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX512VL-NEXT: vmovlhps {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = load <8 x i16>, <8 x i16>* %a0
%2 = shufflevector <8 x i16> %1, <8 x i16> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3>
%3 = bitcast <4 x i16> %2 to <4 x half>
%4 = fpext <4 x half> %3 to <4 x double>
ret <4 x double> %4
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <8 x double> @load_cvt_8i16_to_8f64(<8 x i16>* %a0) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: load_cvt_8i16_to_8f64:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movswl 8(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm1
; AVX1-NEXT: movswl 10(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm2
; AVX1-NEXT: movswl 12(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm3
; AVX1-NEXT: movswl 14(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm4
; AVX1-NEXT: movswl (%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm0
; AVX1-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX1-NEXT: movswl 2(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm5
; AVX1-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX1-NEXT: movswl 4(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm6
; AVX1-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX1-NEXT: movswl 6(%rdi), %eax
; AVX1-NEXT: vmovd %eax, %xmm7
; AVX1-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX1-NEXT: vcvtss2sd %xmm7, %xmm7, %xmm7
; AVX1-NEXT: vcvtss2sd %xmm6, %xmm6, %xmm6
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm6 = xmm6[0],xmm7[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtss2sd %xmm5, %xmm5, %xmm5
; AVX1-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm0 = xmm0[0],xmm5[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm6, %ymm0, %ymm0
; AVX1-NEXT: vcvtss2sd %xmm4, %xmm4, %xmm4
; AVX1-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm3 = xmm3[0],xmm4[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; AVX1-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX1-NEXT: vmovlhps {{.*#+}} xmm1 = xmm1[0],xmm2[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vinsertf128 $1, %xmm3, %ymm1, %ymm1
; AVX1-NEXT: retq
;
; AVX2-LABEL: load_cvt_8i16_to_8f64:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movswl 8(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm1
; AVX2-NEXT: movswl 10(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm2
; AVX2-NEXT: movswl 12(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm3
; AVX2-NEXT: movswl 14(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm4
; AVX2-NEXT: movswl (%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm0
; AVX2-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX2-NEXT: movswl 2(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm5
; AVX2-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX2-NEXT: movswl 4(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm6
; AVX2-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX2-NEXT: movswl 6(%rdi), %eax
; AVX2-NEXT: vmovd %eax, %xmm7
; AVX2-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX2-NEXT: vcvtss2sd %xmm7, %xmm7, %xmm7
; AVX2-NEXT: vcvtss2sd %xmm6, %xmm6, %xmm6
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm6 = xmm6[0],xmm7[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtss2sd %xmm5, %xmm5, %xmm5
; AVX2-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm0 = xmm0[0],xmm5[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm6, %ymm0, %ymm0
; AVX2-NEXT: vcvtss2sd %xmm4, %xmm4, %xmm4
; AVX2-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm3 = xmm3[0],xmm4[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; AVX2-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
[X86] Teach the execution domain fixing tables to use movlhps inplace of unpcklpd for the packed single domain. MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter. llvm-svn: 313509
2017-09-18 12:40:58 +08:00
; AVX2-NEXT: vmovlhps {{.*#+}} xmm1 = xmm1[0],xmm2[0]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vinsertf128 $1, %xmm3, %ymm1, %ymm1
; AVX2-NEXT: retq
;
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-LABEL: load_cvt_8i16_to_8f64:
[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] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: movswl (%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm0
; AVX512-NEXT: vcvtph2ps %xmm0, %xmm0
; AVX512-NEXT: movswl 2(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm1
; AVX512-NEXT: vcvtph2ps %xmm1, %xmm1
; AVX512-NEXT: movswl 4(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm2
; AVX512-NEXT: vcvtph2ps %xmm2, %xmm2
; AVX512-NEXT: movswl 6(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm3
; AVX512-NEXT: vcvtph2ps %xmm3, %xmm3
; AVX512-NEXT: movswl 8(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm4
; AVX512-NEXT: vcvtph2ps %xmm4, %xmm4
; AVX512-NEXT: movswl 10(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm5
; AVX512-NEXT: vcvtph2ps %xmm5, %xmm5
; AVX512-NEXT: movswl 12(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm6
; AVX512-NEXT: vcvtph2ps %xmm6, %xmm6
; AVX512-NEXT: movswl 14(%rdi), %eax
; AVX512-NEXT: vmovd %eax, %xmm7
; AVX512-NEXT: vcvtph2ps %xmm7, %xmm7
; AVX512-NEXT: vcvtss2sd %xmm7, %xmm7, %xmm7
; AVX512-NEXT: vcvtss2sd %xmm6, %xmm6, %xmm6
; AVX512-NEXT: vmovlhps {{.*#+}} xmm6 = xmm6[0],xmm7[0]
; AVX512-NEXT: vcvtss2sd %xmm5, %xmm5, %xmm5
; AVX512-NEXT: vcvtss2sd %xmm4, %xmm4, %xmm4
; AVX512-NEXT: vmovlhps {{.*#+}} xmm4 = xmm4[0],xmm5[0]
; AVX512-NEXT: vinsertf128 $1, %xmm6, %ymm4, %ymm4
; AVX512-NEXT: vcvtss2sd %xmm3, %xmm3, %xmm3
; AVX512-NEXT: vcvtss2sd %xmm2, %xmm2, %xmm2
; AVX512-NEXT: vmovlhps {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; AVX512-NEXT: vcvtss2sd %xmm1, %xmm1, %xmm1
; AVX512-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; AVX512-NEXT: vmovlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; AVX512-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX512-NEXT: vinsertf64x4 $1, %ymm4, %zmm0, %zmm0
; AVX512-NEXT: retq
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
%1 = load <8 x i16>, <8 x i16>* %a0
%2 = bitcast <8 x i16> %1 to <8 x half>
%3 = fpext <8 x half> %2 to <8 x double>
ret <8 x double> %3
}
;
; Float to Half
;
define i16 @cvt_f32_to_i16(float %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: cvt_f32_to_i16:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %eax
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
; ALL-NEXT: # kill: def $ax killed $ax killed $eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: retq
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
%1 = fptrunc float %a0 to half
%2 = bitcast half %1 to i16
ret i16 %2
}
define <4 x i16> @cvt_4f32_to_4i16(<4 x float> %a0) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: cvt_4f32_to_4i16:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: movzwl %cx, %ecx
; ALL-NEXT: orl %eax, %ecx
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %edx
; ALL-NEXT: movzwl %dx, %edx
; ALL-NEXT: orl %eax, %edx
; ALL-NEXT: shlq $32, %rdx
; ALL-NEXT: orq %rcx, %rdx
; ALL-NEXT: vmovq %rdx, %xmm0
; ALL-NEXT: retq
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
%1 = fptrunc <4 x float> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
ret <4 x i16> %2
}
define <8 x i16> @cvt_4f32_to_8i16_undef(<4 x float> %a0) nounwind {
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; ALL-LABEL: cvt_4f32_to_8i16_undef:
; ALL: # %bb.0:
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: movzwl %cx, %ecx
; ALL-NEXT: orl %eax, %ecx
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %edx
; ALL-NEXT: movzwl %dx, %edx
; ALL-NEXT: orl %eax, %edx
; ALL-NEXT: shlq $32, %rdx
; ALL-NEXT: orq %rcx, %rdx
; ALL-NEXT: vmovq %rdx, %xmm0
; ALL-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; ALL-NEXT: retq
%1 = fptrunc <4 x float> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
ret <8 x i16> %3
}
define <8 x i16> @cvt_4f32_to_8i16_zero(<4 x float> %a0) nounwind {
; AVX1-LABEL: cvt_4f32_to_8i16_zero:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: shll $16, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX1-NEXT: vmovd %xmm1, %ecx
; AVX1-NEXT: movzwl %cx, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: shll $16, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX1-NEXT: vmovd %xmm0, %edx
; AVX1-NEXT: movzwl %dx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: shlq $32, %rdx
; AVX1-NEXT: orq %rcx, %rdx
; AVX1-NEXT: vmovq %rdx, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-LABEL: cvt_4f32_to_8i16_zero:
; AVX2-SLOW: # %bb.0:
; AVX2-SLOW-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-SLOW-NEXT: vmovd %xmm1, %eax
; AVX2-SLOW-NEXT: shll $16, %eax
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX2-SLOW-NEXT: vmovd %xmm1, %ecx
; AVX2-SLOW-NEXT: movzwl %cx, %ecx
; AVX2-SLOW-NEXT: orl %eax, %ecx
; AVX2-SLOW-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-SLOW-NEXT: vmovd %xmm1, %eax
; AVX2-SLOW-NEXT: shll $16, %eax
; AVX2-SLOW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-SLOW-NEXT: vmovd %xmm0, %edx
; AVX2-SLOW-NEXT: movzwl %dx, %edx
; AVX2-SLOW-NEXT: orl %eax, %edx
; AVX2-SLOW-NEXT: shlq $32, %rdx
; AVX2-SLOW-NEXT: orq %rcx, %rdx
; AVX2-SLOW-NEXT: vmovq %rdx, %xmm0
; AVX2-SLOW-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX2-SLOW-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
; AVX2-SLOW-NEXT: retq
;
; AVX2-FAST-LABEL: cvt_4f32_to_8i16_zero:
; AVX2-FAST: # %bb.0:
; AVX2-FAST-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-FAST-NEXT: vmovd %xmm1, %eax
; AVX2-FAST-NEXT: shll $16, %eax
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX2-FAST-NEXT: vmovd %xmm1, %ecx
; AVX2-FAST-NEXT: movzwl %cx, %ecx
; AVX2-FAST-NEXT: orl %eax, %ecx
; AVX2-FAST-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-FAST-NEXT: vmovd %xmm1, %eax
; AVX2-FAST-NEXT: shll $16, %eax
; AVX2-FAST-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-FAST-NEXT: vmovd %xmm0, %edx
; AVX2-FAST-NEXT: movzwl %dx, %edx
; AVX2-FAST-NEXT: orl %eax, %edx
; AVX2-FAST-NEXT: shlq $32, %rdx
; AVX2-FAST-NEXT: orq %rcx, %rdx
; AVX2-FAST-NEXT: vmovq %rdx, %xmm0
; AVX2-FAST-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
; AVX2-FAST-NEXT: retq
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512F-LABEL: cvt_4f32_to_8i16_zero:
[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] Use 512-bit vcvtps2ph/vcvtph2ps to implement fp_to_f16/f16_to_fp when F16C and VLX are not supported. Fixes PR23941. llvm-svn: 281958
2016-09-20 13:44:47 +08:00
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512F-NEXT: vmovd %xmm1, %eax
; AVX512F-NEXT: shll $16, %eax
; AVX512F-NEXT: vcvtps2ph $4, %xmm0, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm1, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: movzwl %cx, %ecx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: orl %eax, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX512F-NEXT: vcvtps2ph $4, %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm1, %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: shll $16, %eax
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vcvtps2ph $4, %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm0, %edx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: movzwl %dx, %edx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: orl %eax, %edx
; AVX512F-NEXT: shlq $32, %rdx
; AVX512F-NEXT: orq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX512F-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512F-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-LABEL: cvt_4f32_to_8i16_zero:
[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
; AVX512VL: # %bb.0:
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX512VL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512VL-NEXT: vmovd %xmm1, %eax
; AVX512VL-NEXT: shll $16, %eax
; AVX512VL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX512VL-NEXT: vmovd %xmm1, %ecx
; AVX512VL-NEXT: movzwl %cx, %ecx
; AVX512VL-NEXT: orl %eax, %ecx
; AVX512VL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX512VL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512VL-NEXT: vmovd %xmm1, %eax
; AVX512VL-NEXT: shll $16, %eax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %xmm0, %edx
; AVX512VL-NEXT: movzwl %dx, %edx
; AVX512VL-NEXT: orl %eax, %edx
; AVX512VL-NEXT: shlq $32, %rdx
; AVX512VL-NEXT: orq %rcx, %rdx
; AVX512VL-NEXT: vmovq %rdx, %xmm0
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
%1 = fptrunc <4 x float> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> zeroinitializer, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
ret <8 x i16> %3
}
define <8 x i16> @cvt_8f32_to_8i16(<8 x float> %a0) nounwind {
; ALL-LABEL: cvt_8f32_to_8i16:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: movzwl %cx, %ecx
; ALL-NEXT: orl %eax, %ecx
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %edx
; ALL-NEXT: shll $16, %edx
; ALL-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: movzwl %ax, %eax
; ALL-NEXT: orl %edx, %eax
; ALL-NEXT: shlq $32, %rax
; ALL-NEXT: orq %rcx, %rax
; ALL-NEXT: vextractf128 $1, %ymm0, %xmm0
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: shll $16, %ecx
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; ALL-NEXT: vmovd %xmm1, %edx
; ALL-NEXT: movzwl %dx, %edx
; ALL-NEXT: orl %ecx, %edx
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: shll $16, %ecx
; ALL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %esi
; ALL-NEXT: movzwl %si, %esi
; ALL-NEXT: orl %ecx, %esi
; ALL-NEXT: shlq $32, %rsi
; ALL-NEXT: orq %rdx, %rsi
; ALL-NEXT: vmovq %rsi, %xmm0
; ALL-NEXT: vmovq %rax, %xmm1
; ALL-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; ALL-NEXT: vzeroupper
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <8 x float> %a0 to <8 x half>
%2 = bitcast <8 x half> %1 to <8 x i16>
ret <8 x i16> %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <16 x i16> @cvt_16f32_to_16i16(<16 x float> %a0) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: cvt_16f32_to_16i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm2
; AVX1-NEXT: vmovd %xmm2, %eax
; AVX1-NEXT: vmovshdup {{.*#+}} xmm2 = xmm1[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX1-NEXT: vmovd %eax, %xmm3
; AVX1-NEXT: vmovd %xmm2, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm2 = xmm1[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX1-NEXT: vpinsrw $1, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm2, %eax
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm1[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vpinsrw $2, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm2, %xmm1
; AVX1-NEXT: vpinsrw $3, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vmovshdup {{.*#+}} xmm1 = xmm2[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vpinsrw $4, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm1 = xmm2[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vpinsrw $5, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX1-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX1-NEXT: vpinsrw $6, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm2, %eax
; AVX1-NEXT: vpinsrw $7, %eax, %xmm3, %xmm2
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vmovd %eax, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vpinsrw $1, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX1-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX1-NEXT: vpinsrw $2, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm0
; AVX1-NEXT: vpinsrw $3, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vmovshdup {{.*#+}} xmm0 = xmm1[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX1-NEXT: vpinsrw $4, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vpermilps {{.*#+}} xmm0 = xmm1[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX1-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vpinsrw $5, %eax, %xmm3, %xmm3
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vpinsrw $6, %eax, %xmm3, %xmm1
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: vpinsrw $7, %eax, %xmm1, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_16f32_to_16i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm2
; AVX2-NEXT: vmovd %xmm2, %eax
; AVX2-NEXT: vmovshdup {{.*#+}} xmm2 = xmm1[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX2-NEXT: vmovd %eax, %xmm3
; AVX2-NEXT: vmovd %xmm2, %eax
; AVX2-NEXT: vpermilpd {{.*#+}} xmm2 = xmm1[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX2-NEXT: vpinsrw $1, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm2, %eax
; AVX2-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX2-NEXT: vpermilps {{.*#+}} xmm1 = xmm1[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vpinsrw $2, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vcvtps2ph $4, %xmm2, %xmm1
; AVX2-NEXT: vpinsrw $3, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vmovshdup {{.*#+}} xmm1 = xmm2[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vpinsrw $4, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vpermilpd {{.*#+}} xmm1 = xmm2[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vpinsrw $5, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX2-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX2-NEXT: vpinsrw $6, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm2, %eax
; AVX2-NEXT: vpinsrw $7, %eax, %xmm3, %xmm2
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vmovd %eax, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vpinsrw $1, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX2-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-NEXT: vpinsrw $2, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm0
; AVX2-NEXT: vpinsrw $3, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vmovshdup {{.*#+}} xmm0 = xmm1[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-NEXT: vpinsrw $4, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vpermilps {{.*#+}} xmm0 = xmm1[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vpinsrw $5, %eax, %xmm3, %xmm3
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vpinsrw $6, %eax, %xmm3, %xmm1
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: vpinsrw $7, %eax, %xmm1, %xmm0
; AVX2-NEXT: vinserti128 $1, %xmm2, %ymm0, %ymm0
; AVX2-NEXT: retq
;
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-LABEL: cvt_16f32_to_16i16:
[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] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vextractf64x4 $1, %zmm0, %ymm1
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm2
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vmovshdup {{.*#+}} xmm2 = xmm1[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX512-NEXT: vmovd %eax, %xmm3
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm2 = xmm1[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX512-NEXT: vpinsrw $1, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX512-NEXT: vpermilps {{.*#+}} xmm1 = xmm1[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512-NEXT: vpinsrw $2, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm1
; AVX512-NEXT: vpinsrw $3, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vmovshdup {{.*#+}} xmm1 = xmm2[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512-NEXT: vpinsrw $4, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm1 = xmm2[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512-NEXT: vpinsrw $5, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX512-NEXT: vpermilps {{.*#+}} xmm2 = xmm2[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX512-NEXT: vpinsrw $6, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vpinsrw $7, %eax, %xmm3, %xmm2
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512-NEXT: vmovd %eax, %xmm3
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512-NEXT: vpinsrw $1, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX512-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512-NEXT: vpinsrw $2, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm0
; AVX512-NEXT: vpinsrw $3, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vmovshdup {{.*#+}} xmm0 = xmm1[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512-NEXT: vpinsrw $4, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm1[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512-NEXT: vpinsrw $5, %eax, %xmm3, %xmm3
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vpermilps {{.*#+}} xmm0 = xmm1[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512-NEXT: vpinsrw $6, %eax, %xmm3, %xmm1
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: vpinsrw $7, %eax, %xmm1, %xmm0
; AVX512-NEXT: vinserti128 $1, %xmm2, %ymm0, %ymm0
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <16 x float> %a0 to <16 x half>
%2 = bitcast <16 x half> %1 to <16 x i16>
ret <16 x i16> %2
}
;
; Float to Half (Store)
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_f32_to_i16(float %a0, i16* %a1) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: store_cvt_f32_to_i16:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %eax
; ALL-NEXT: movw %ax, (%rdi)
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc float %a0 to half
%2 = bitcast half %1 to i16
store i16 %2, i16* %a1
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_4f32_to_4i16(<4 x float> %a0, <4 x i16>* %a1) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: store_cvt_4f32_to_4i16:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %edx
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %esi
; ALL-NEXT: movw %si, (%rdi)
; ALL-NEXT: movw %dx, 6(%rdi)
; ALL-NEXT: movw %cx, 4(%rdi)
; ALL-NEXT: movw %ax, 2(%rdi)
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <4 x float> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
store <4 x i16> %2, <4 x i16>* %a1
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_4f32_to_8i16_undef(<4 x float> %a0, <8 x i16>* %a1) nounwind {
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; ALL-LABEL: store_cvt_4f32_to_8i16_undef:
; ALL: # %bb.0:
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; ALL-NEXT: vmovd %xmm1, %ecx
; ALL-NEXT: movzwl %cx, %ecx
; ALL-NEXT: orl %eax, %ecx
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %eax
; ALL-NEXT: shll $16, %eax
; ALL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %edx
; ALL-NEXT: movzwl %dx, %edx
; ALL-NEXT: orl %eax, %edx
; ALL-NEXT: shlq $32, %rdx
; ALL-NEXT: orq %rcx, %rdx
; ALL-NEXT: vmovq %rdx, %xmm0
; ALL-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; ALL-NEXT: vmovdqa %xmm0, (%rdi)
; ALL-NEXT: retq
%1 = fptrunc <4 x float> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
store <8 x i16> %3, <8 x i16>* %a1
ret void
}
define void @store_cvt_4f32_to_8i16_zero(<4 x float> %a0, <8 x i16>* %a1) nounwind {
; AVX1-LABEL: store_cvt_4f32_to_8i16_zero:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: shll $16, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX1-NEXT: vmovd %xmm1, %ecx
; AVX1-NEXT: movzwl %cx, %ecx
; AVX1-NEXT: orl %eax, %ecx
; AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: shll $16, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX1-NEXT: vmovd %xmm0, %edx
; AVX1-NEXT: movzwl %dx, %edx
; AVX1-NEXT: orl %eax, %edx
; AVX1-NEXT: shlq $32, %rdx
; AVX1-NEXT: orq %rcx, %rdx
; AVX1-NEXT: vmovq %rdx, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX1-NEXT: vmovdqa %xmm0, (%rdi)
; AVX1-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-LABEL: store_cvt_4f32_to_8i16_zero:
; AVX2-SLOW: # %bb.0:
; AVX2-SLOW-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-SLOW-NEXT: vmovd %xmm1, %eax
; AVX2-SLOW-NEXT: shll $16, %eax
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX2-SLOW-NEXT: vmovd %xmm1, %ecx
; AVX2-SLOW-NEXT: movzwl %cx, %ecx
; AVX2-SLOW-NEXT: orl %eax, %ecx
; AVX2-SLOW-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-SLOW-NEXT: vmovd %xmm1, %eax
; AVX2-SLOW-NEXT: shll $16, %eax
; AVX2-SLOW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-SLOW-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-SLOW-NEXT: vmovd %xmm0, %edx
; AVX2-SLOW-NEXT: movzwl %dx, %edx
; AVX2-SLOW-NEXT: orl %eax, %edx
; AVX2-SLOW-NEXT: shlq $32, %rdx
; AVX2-SLOW-NEXT: orq %rcx, %rdx
; AVX2-SLOW-NEXT: vmovq %rdx, %xmm0
; AVX2-SLOW-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX2-SLOW-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
; AVX2-SLOW-NEXT: vmovdqa %xmm0, (%rdi)
; AVX2-SLOW-NEXT: retq
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-LABEL: store_cvt_4f32_to_8i16_zero:
; AVX2-FAST: # %bb.0:
; AVX2-FAST-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-FAST-NEXT: vmovd %xmm1, %eax
; AVX2-FAST-NEXT: shll $16, %eax
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX2-FAST-NEXT: vmovd %xmm1, %ecx
; AVX2-FAST-NEXT: movzwl %cx, %ecx
; AVX2-FAST-NEXT: orl %eax, %ecx
; AVX2-FAST-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-FAST-NEXT: vmovd %xmm1, %eax
; AVX2-FAST-NEXT: shll $16, %eax
; AVX2-FAST-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-FAST-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-FAST-NEXT: vmovd %xmm0, %edx
; AVX2-FAST-NEXT: movzwl %dx, %edx
; AVX2-FAST-NEXT: orl %eax, %edx
; AVX2-FAST-NEXT: shlq $32, %rdx
; AVX2-FAST-NEXT: orq %rcx, %rdx
; AVX2-FAST-NEXT: vmovq %rdx, %xmm0
; AVX2-FAST-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
; AVX2-FAST-NEXT: vmovdqa %xmm0, (%rdi)
; AVX2-FAST-NEXT: retq
;
; AVX512F-LABEL: store_cvt_4f32_to_8i16_zero:
[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] Use 512-bit vcvtps2ph/vcvtph2ps to implement fp_to_f16/f16_to_fp when F16C and VLX are not supported. Fixes PR23941. llvm-svn: 281958
2016-09-20 13:44:47 +08:00
; AVX512F-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512F-NEXT: vmovd %xmm1, %eax
; AVX512F-NEXT: shll $16, %eax
; AVX512F-NEXT: vcvtps2ph $4, %xmm0, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm1, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: movzwl %cx, %ecx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: orl %eax, %ecx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX512F-NEXT: vcvtps2ph $4, %xmm1, %xmm1
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm1, %eax
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: shll $16, %eax
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512F-NEXT: vcvtps2ph $4, %xmm0, %xmm0
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovd %xmm0, %edx
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512F-NEXT: movzwl %dx, %edx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: orl %eax, %edx
; AVX512F-NEXT: shlq $32, %rdx
; AVX512F-NEXT: orq %rcx, %rdx
; AVX512F-NEXT: vmovq %rdx, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX512F-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512F-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovdqa %xmm0, (%rdi)
; AVX512F-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-LABEL: store_cvt_4f32_to_8i16_zero:
[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
; AVX512VL: # %bb.0:
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; AVX512VL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512VL-NEXT: vmovd %xmm1, %eax
; AVX512VL-NEXT: shll $16, %eax
; AVX512VL-NEXT: vcvtps2ph $4, %xmm0, %xmm1
; AVX512VL-NEXT: vmovd %xmm1, %ecx
; AVX512VL-NEXT: movzwl %cx, %ecx
; AVX512VL-NEXT: orl %eax, %ecx
; AVX512VL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; AVX512VL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512VL-NEXT: vmovd %xmm1, %eax
; AVX512VL-NEXT: shll $16, %eax
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[AVX-512] Add support for lowering fp_to_f16 and f16_to_fp when VLX is supported regardless of whether F16C is also supported. Still need to add support for lowering using AVX512F when neither VLX or F16C is supported. llvm-svn: 281884
2016-09-19 10:53:37 +08:00
; AVX512VL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512VL-NEXT: vmovd %xmm0, %edx
; AVX512VL-NEXT: movzwl %dx, %edx
; AVX512VL-NEXT: orl %eax, %edx
; AVX512VL-NEXT: shlq $32, %rdx
; AVX512VL-NEXT: orq %rcx, %rdx
; AVX512VL-NEXT: vmovq %rdx, %xmm0
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
This is a large patch for X86 AVX-512 of an optimization for reducing code size by encoding EVEX AVX-512 instructions using the shorter VEX encoding when possible. There are cases of AVX-512 instructions that have two possible encodings. This is the case with instructions that use vector registers with low indexes of 0 - 15 and do not use the zmm registers or the mask k registers. The EVEX encoding prefix requires 4 bytes whereas the VEX prefix can take only up to 3 bytes. Consequently, using the VEX encoding for these instructions results in a code size reduction of ~2 bytes even though it is compiled with the AVX-512 features enabled. Reviewers: Craig Topper, Zvi Rackoover, Elena Demikhovsky Differential Revision: https://reviews.llvm.org/D27901 llvm-svn: 290663
2016-12-28 18:12:48 +08:00
; AVX512VL-NEXT: vmovdqa %xmm0, (%rdi)
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <4 x float> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> zeroinitializer, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
store <8 x i16> %3, <8 x i16>* %a1
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_8f32_to_8i16(<8 x float> %a0, <8 x i16>* %a1) nounwind {
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-LABEL: store_cvt_8f32_to_8i16:
[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
; ALL: # %bb.0:
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; ALL-NEXT: vmovshdup {{.*#+}} xmm1 = xmm0[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %r8d
; ALL-NEXT: vpermilpd {{.*#+}} xmm1 = xmm0[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %r9d
; ALL-NEXT: vpermilps {{.*#+}} xmm1 = xmm0[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; ALL-NEXT: vmovd %xmm1, %r10d
; ALL-NEXT: vextractf128 $1, %ymm0, %xmm1
; ALL-NEXT: vmovshdup {{.*#+}} xmm2 = xmm1[1,1,3,3]
; ALL-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; ALL-NEXT: vmovd %xmm2, %r11d
; ALL-NEXT: vpermilpd {{.*#+}} xmm2 = xmm1[1,0]
; ALL-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; ALL-NEXT: vmovd %xmm2, %eax
; ALL-NEXT: vpermilps {{.*#+}} xmm2 = xmm1[3,1,2,3]
; ALL-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; ALL-NEXT: vmovd %xmm2, %ecx
; ALL-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; ALL-NEXT: vmovd %xmm0, %edx
; ALL-NEXT: vcvtps2ph $4, %xmm1, %xmm0
; ALL-NEXT: vmovd %xmm0, %esi
; ALL-NEXT: movw %si, 8(%rdi)
; ALL-NEXT: movw %dx, (%rdi)
; ALL-NEXT: movw %cx, 14(%rdi)
; ALL-NEXT: movw %ax, 12(%rdi)
; ALL-NEXT: movw %r11w, 10(%rdi)
; ALL-NEXT: movw %r10w, 6(%rdi)
; ALL-NEXT: movw %r9w, 4(%rdi)
; ALL-NEXT: movw %r8w, 2(%rdi)
; ALL-NEXT: vzeroupper
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <8 x float> %a0 to <8 x half>
%2 = bitcast <8 x half> %1 to <8 x i16>
store <8 x i16> %2, <8 x i16>* %a1
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_16f32_to_16i16(<16 x float> %a0, <16 x i16>* %a1) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: store_cvt_16f32_to_16i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vcvtps2ph $4, %xmm3, %xmm4
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm4
; AVX1-NEXT: movw %ax, 24(%rdi)
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm2, %xmm4
; AVX1-NEXT: movw %ax, 16(%rdi)
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm4
; AVX1-NEXT: movw %ax, 8(%rdi)
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: vpermilps {{.*#+}} xmm4 = xmm3[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX1-NEXT: movw %ax, (%rdi)
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm4 = xmm3[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX1-NEXT: movw %ax, 30(%rdi)
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: vmovshdup {{.*#+}} xmm4 = xmm0[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX1-NEXT: vmovshdup {{.*#+}} xmm3 = xmm3[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX1-NEXT: movw %ax, 28(%rdi)
; AVX1-NEXT: vmovd %xmm3, %eax
; AVX1-NEXT: vpermilps {{.*#+}} xmm3 = xmm1[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX1-NEXT: movw %ax, 26(%rdi)
; AVX1-NEXT: vmovd %xmm3, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm3 = xmm1[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX1-NEXT: movw %ax, 22(%rdi)
; AVX1-NEXT: vmovd %xmm3, %eax
; AVX1-NEXT: vpermilpd {{.*#+}} xmm3 = xmm0[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX1-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX1-NEXT: vmovshdup {{.*#+}} xmm1 = xmm1[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: movw %ax, 20(%rdi)
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vpermilps {{.*#+}} xmm1 = xmm2[3,1,2,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: movw %ax, 18(%rdi)
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: vmovshdup {{.*#+}} xmm1 = xmm2[1,1,3,3]
; AVX1-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX1-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX1-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX1-NEXT: movw %ax, 14(%rdi)
; AVX1-NEXT: vmovd %xmm2, %eax
; AVX1-NEXT: movw %ax, 12(%rdi)
; AVX1-NEXT: vmovd %xmm1, %eax
; AVX1-NEXT: movw %ax, 10(%rdi)
; AVX1-NEXT: vmovd %xmm0, %eax
; AVX1-NEXT: movw %ax, 6(%rdi)
; AVX1-NEXT: vmovd %xmm3, %eax
; AVX1-NEXT: movw %ax, 4(%rdi)
; AVX1-NEXT: vmovd %xmm4, %eax
; AVX1-NEXT: movw %ax, 2(%rdi)
; AVX1-NEXT: vzeroupper
; AVX1-NEXT: retq
;
; AVX2-LABEL: store_cvt_16f32_to_16i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX2-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX2-NEXT: vcvtps2ph $4, %xmm3, %xmm4
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm4
; AVX2-NEXT: movw %ax, 24(%rdi)
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: vcvtps2ph $4, %xmm2, %xmm4
; AVX2-NEXT: movw %ax, 16(%rdi)
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: vcvtps2ph $4, %xmm0, %xmm4
; AVX2-NEXT: movw %ax, 8(%rdi)
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: vpermilps {{.*#+}} xmm4 = xmm3[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX2-NEXT: movw %ax, (%rdi)
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: vpermilpd {{.*#+}} xmm4 = xmm3[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX2-NEXT: movw %ax, 30(%rdi)
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: vmovshdup {{.*#+}} xmm4 = xmm0[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX2-NEXT: vmovshdup {{.*#+}} xmm3 = xmm3[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX2-NEXT: movw %ax, 28(%rdi)
; AVX2-NEXT: vmovd %xmm3, %eax
; AVX2-NEXT: vpermilps {{.*#+}} xmm3 = xmm1[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX2-NEXT: movw %ax, 26(%rdi)
; AVX2-NEXT: vmovd %xmm3, %eax
; AVX2-NEXT: vpermilpd {{.*#+}} xmm3 = xmm1[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX2-NEXT: movw %ax, 22(%rdi)
; AVX2-NEXT: vmovd %xmm3, %eax
; AVX2-NEXT: vpermilpd {{.*#+}} xmm3 = xmm0[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX2-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX2-NEXT: vmovshdup {{.*#+}} xmm1 = xmm1[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: movw %ax, 20(%rdi)
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vpermilps {{.*#+}} xmm1 = xmm2[3,1,2,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: movw %ax, 18(%rdi)
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: vmovshdup {{.*#+}} xmm1 = xmm2[1,1,3,3]
; AVX2-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX2-NEXT: vpermilpd {{.*#+}} xmm2 = xmm2[1,0]
; AVX2-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX2-NEXT: movw %ax, 14(%rdi)
; AVX2-NEXT: vmovd %xmm2, %eax
; AVX2-NEXT: movw %ax, 12(%rdi)
; AVX2-NEXT: vmovd %xmm1, %eax
; AVX2-NEXT: movw %ax, 10(%rdi)
; AVX2-NEXT: vmovd %xmm0, %eax
; AVX2-NEXT: movw %ax, 6(%rdi)
; AVX2-NEXT: vmovd %xmm3, %eax
; AVX2-NEXT: movw %ax, 4(%rdi)
; AVX2-NEXT: vmovd %xmm4, %eax
; AVX2-NEXT: movw %ax, 2(%rdi)
; AVX2-NEXT: vzeroupper
; AVX2-NEXT: retq
;
[X86] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-LABEL: store_cvt_16f32_to_16i16:
[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] Make FeatureAVX512 imply FeatureF16C. The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
2017-11-07 06:49:04 +08:00
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm1
; AVX512-NEXT: vextractf64x4 $1, %zmm0, %ymm2
; AVX512-NEXT: vextractf128 $1, %ymm2, %xmm3
; AVX512-NEXT: vcvtps2ph $4, %xmm3, %xmm4
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm4
; AVX512-NEXT: movw %ax, 24(%rdi)
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm4
; AVX512-NEXT: movw %ax, 16(%rdi)
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm4
; AVX512-NEXT: movw %ax, 8(%rdi)
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: vpermilps {{.*#+}} xmm4 = xmm3[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX512-NEXT: movw %ax, (%rdi)
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm4 = xmm3[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX512-NEXT: movw %ax, 30(%rdi)
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: vmovshdup {{.*#+}} xmm4 = xmm0[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm4, %xmm4
; AVX512-NEXT: vmovshdup {{.*#+}} xmm3 = xmm3[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX512-NEXT: movw %ax, 28(%rdi)
; AVX512-NEXT: vmovd %xmm3, %eax
; AVX512-NEXT: vpermilps {{.*#+}} xmm3 = xmm2[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX512-NEXT: movw %ax, 26(%rdi)
; AVX512-NEXT: vmovd %xmm3, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm3 = xmm2[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX512-NEXT: movw %ax, 22(%rdi)
; AVX512-NEXT: vmovd %xmm3, %eax
; AVX512-NEXT: vpermilpd {{.*#+}} xmm3 = xmm0[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm3, %xmm3
; AVX512-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; AVX512-NEXT: vmovshdup {{.*#+}} xmm2 = xmm2[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX512-NEXT: movw %ax, 20(%rdi)
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vpermilps {{.*#+}} xmm2 = xmm1[3,1,2,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX512-NEXT: movw %ax, 18(%rdi)
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: vmovshdup {{.*#+}} xmm2 = xmm1[1,1,3,3]
; AVX512-NEXT: vcvtps2ph $4, %xmm2, %xmm2
; AVX512-NEXT: vpermilpd {{.*#+}} xmm1 = xmm1[1,0]
; AVX512-NEXT: vcvtps2ph $4, %xmm1, %xmm1
; AVX512-NEXT: movw %ax, 14(%rdi)
; AVX512-NEXT: vmovd %xmm1, %eax
; AVX512-NEXT: movw %ax, 12(%rdi)
; AVX512-NEXT: vmovd %xmm2, %eax
; AVX512-NEXT: movw %ax, 10(%rdi)
; AVX512-NEXT: vmovd %xmm0, %eax
; AVX512-NEXT: movw %ax, 6(%rdi)
; AVX512-NEXT: vmovd %xmm3, %eax
; AVX512-NEXT: movw %ax, 4(%rdi)
; AVX512-NEXT: vmovd %xmm4, %eax
; AVX512-NEXT: movw %ax, 2(%rdi)
; AVX512-NEXT: vzeroupper
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <16 x float> %a0 to <16 x half>
%2 = bitcast <16 x half> %1 to <16 x i16>
store <16 x i16> %2, <16 x i16>* %a1
ret void
}
;
; Double to Half
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define i16 @cvt_f64_to_i16(double %a0) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; ALL-LABEL: cvt_f64_to_i16:
[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
; ALL: # %bb.0:
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; ALL-NEXT: jmp __truncdfhf2 # TAILCALL
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc double %a0 to half
%2 = bitcast half %1 to i16
ret i16 %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <2 x i16> @cvt_2f64_to_2i16(<2 x double> %a0) nounwind {
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-LABEL: cvt_2f64_to_2i16:
[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
; ALL: # %bb.0:
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-NEXT: pushq %rbx
; ALL-NEXT: subq $16, %rsp
; ALL-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; ALL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; ALL-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; ALL-NEXT: movl %eax, %ebx
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-NEXT: shll $16, %ebx
; ALL-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; ALL-NEXT: callq __truncdfhf2
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-NEXT: movzwl %ax, %eax
; ALL-NEXT: orl %ebx, %eax
; ALL-NEXT: vmovd %eax, %xmm0
; ALL-NEXT: addq $16, %rsp
; ALL-NEXT: popq %rbx
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <2 x double> %a0 to <2 x half>
%2 = bitcast <2 x half> %1 to <2 x i16>
ret <2 x i16> %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <4 x i16> @cvt_4f64_to_4i16(<4 x double> %a0) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: cvt_4f64_to_4i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $40, %rsp
; AVX1-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %r14d
; AVX1-NEXT: orl %ebx, %r14d
[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: vmovups (%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %eax
; AVX1-NEXT: orl %ebx, %eax
; AVX1-NEXT: shlq $32, %rax
; AVX1-NEXT: orq %r14, %rax
; AVX1-NEXT: vmovq %rax, %xmm0
; AVX1-NEXT: addq $40, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_4f64_to_4i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: pushq %r14
; AVX2-NEXT: pushq %rbx
; AVX2-NEXT: subq $40, %rsp
; AVX2-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %r14d
; AVX2-NEXT: orl %ebx, %r14d
; AVX2-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %eax
; AVX2-NEXT: orl %ebx, %eax
; AVX2-NEXT: shlq $32, %rax
; AVX2-NEXT: orq %r14, %rax
; AVX2-NEXT: vmovq %rax, %xmm0
; AVX2-NEXT: addq $40, %rsp
; AVX2-NEXT: popq %rbx
; AVX2-NEXT: popq %r14
; AVX2-NEXT: retq
;
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-LABEL: cvt_4f64_to_4i16:
[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:
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: pushq %r14
; AVX512-NEXT: pushq %rbx
; AVX512-NEXT: subq $40, %rsp
; AVX512-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512-NEXT: movl %eax, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movzwl %ax, %r14d
; AVX512-NEXT: orl %ebx, %r14d
; AVX512-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512-NEXT: movl %eax, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movzwl %ax, %eax
; AVX512-NEXT: orl %ebx, %eax
; AVX512-NEXT: shlq $32, %rax
; AVX512-NEXT: orq %r14, %rax
; AVX512-NEXT: vmovq %rax, %xmm0
; AVX512-NEXT: addq $40, %rsp
; AVX512-NEXT: popq %rbx
; AVX512-NEXT: popq %r14
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <4 x double> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
ret <4 x i16> %2
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define <8 x i16> @cvt_4f64_to_8i16_undef(<4 x double> %a0) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: cvt_4f64_to_8i16_undef:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $40, %rsp
; AVX1-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %r14d
; AVX1-NEXT: orl %ebx, %r14d
[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: vmovups (%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %eax
; AVX1-NEXT: orl %ebx, %eax
; AVX1-NEXT: shlq $32, %rax
; AVX1-NEXT: orq %r14, %rax
; AVX1-NEXT: vmovq %rax, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: addq $40, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_4f64_to_8i16_undef:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: pushq %r14
; AVX2-NEXT: pushq %rbx
; AVX2-NEXT: subq $40, %rsp
; AVX2-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %r14d
; AVX2-NEXT: orl %ebx, %r14d
; AVX2-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %eax
; AVX2-NEXT: orl %ebx, %eax
; AVX2-NEXT: shlq $32, %rax
; AVX2-NEXT: orq %r14, %rax
; AVX2-NEXT: vmovq %rax, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX2-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: addq $40, %rsp
; AVX2-NEXT: popq %rbx
; AVX2-NEXT: popq %r14
; AVX2-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-LABEL: cvt_4f64_to_8i16_undef:
; AVX512: # %bb.0:
; AVX512-NEXT: pushq %r14
; AVX512-NEXT: pushq %rbx
; AVX512-NEXT: subq $40, %rsp
; AVX512-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movl %eax, %ebx
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movzwl %ax, %r14d
; AVX512-NEXT: orl %ebx, %r14d
; AVX512-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movl %eax, %ebx
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movzwl %ax, %eax
; AVX512-NEXT: orl %ebx, %eax
; AVX512-NEXT: shlq $32, %rax
; AVX512-NEXT: orq %r14, %rax
; AVX512-NEXT: vmovq %rax, %xmm0
; AVX512-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX512-NEXT: addq $40, %rsp
; AVX512-NEXT: popq %rbx
; AVX512-NEXT: popq %r14
; AVX512-NEXT: retq
%1 = fptrunc <4 x double> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
ret <8 x i16> %3
}
define <8 x i16> @cvt_4f64_to_8i16_zero(<4 x double> %a0) nounwind {
; AVX1-LABEL: cvt_4f64_to_8i16_zero:
; AVX1: # %bb.0:
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $40, %rsp
; AVX1-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movl %eax, %ebx
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movzwl %ax, %r14d
; AVX1-NEXT: orl %ebx, %r14d
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movl %eax, %ebx
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movzwl %ax, %eax
; AVX1-NEXT: orl %ebx, %eax
; AVX1-NEXT: shlq $32, %rax
; AVX1-NEXT: orq %r14, %rax
; AVX1-NEXT: vmovq %rax, %xmm0
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX1-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
; AVX1-NEXT: addq $40, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: retq
;
; AVX2-SLOW-LABEL: cvt_4f64_to_8i16_zero:
; AVX2-SLOW: # %bb.0:
; AVX2-SLOW-NEXT: pushq %r14
; AVX2-SLOW-NEXT: pushq %rbx
; AVX2-SLOW-NEXT: subq $40, %rsp
; AVX2-SLOW-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-SLOW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-SLOW-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movl %eax, %ebx
; AVX2-SLOW-NEXT: shll $16, %ebx
; AVX2-SLOW-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX2-SLOW-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX2-SLOW-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movzwl %ax, %r14d
; AVX2-SLOW-NEXT: orl %ebx, %r14d
; AVX2-SLOW-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-SLOW-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-SLOW-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-SLOW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-SLOW-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movl %eax, %ebx
; AVX2-SLOW-NEXT: shll $16, %ebx
; AVX2-SLOW-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movzwl %ax, %eax
; AVX2-SLOW-NEXT: orl %ebx, %eax
; AVX2-SLOW-NEXT: shlq $32, %rax
; AVX2-SLOW-NEXT: orq %r14, %rax
; AVX2-SLOW-NEXT: vmovq %rax, %xmm0
; AVX2-SLOW-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX2-SLOW-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
; AVX2-SLOW-NEXT: addq $40, %rsp
; AVX2-SLOW-NEXT: popq %rbx
; AVX2-SLOW-NEXT: popq %r14
; AVX2-SLOW-NEXT: retq
;
; AVX2-FAST-LABEL: cvt_4f64_to_8i16_zero:
; AVX2-FAST: # %bb.0:
; AVX2-FAST-NEXT: pushq %r14
; AVX2-FAST-NEXT: pushq %rbx
; AVX2-FAST-NEXT: subq $40, %rsp
; AVX2-FAST-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-FAST-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-FAST-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movl %eax, %ebx
; AVX2-FAST-NEXT: shll $16, %ebx
; AVX2-FAST-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX2-FAST-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX2-FAST-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movzwl %ax, %r14d
; AVX2-FAST-NEXT: orl %ebx, %r14d
; AVX2-FAST-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-FAST-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-FAST-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-FAST-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-FAST-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movl %eax, %ebx
; AVX2-FAST-NEXT: shll $16, %ebx
; AVX2-FAST-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movzwl %ax, %eax
; AVX2-FAST-NEXT: orl %ebx, %eax
; AVX2-FAST-NEXT: shlq $32, %rax
; AVX2-FAST-NEXT: orq %r14, %rax
; AVX2-FAST-NEXT: vmovq %rax, %xmm0
; AVX2-FAST-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
; AVX2-FAST-NEXT: addq $40, %rsp
; AVX2-FAST-NEXT: popq %rbx
; AVX2-FAST-NEXT: popq %r14
; AVX2-FAST-NEXT: retq
;
; AVX512F-LABEL: cvt_4f64_to_8i16_zero:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: pushq %r14
; AVX512F-NEXT: pushq %rbx
; AVX512F-NEXT: subq $40, %rsp
; AVX512F-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512F-NEXT: movl %eax, %ebx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shll $16, %ebx
; AVX512F-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movzwl %ax, %r14d
; AVX512F-NEXT: orl %ebx, %r14d
; AVX512F-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX512F-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512F-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512F-NEXT: movl %eax, %ebx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shll $16, %ebx
; AVX512F-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movzwl %ax, %eax
; AVX512F-NEXT: orl %ebx, %eax
; AVX512F-NEXT: shlq $32, %rax
; AVX512F-NEXT: orq %r14, %rax
; AVX512F-NEXT: vmovq %rax, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX512F-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512F-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: addq $40, %rsp
; AVX512F-NEXT: popq %rbx
; AVX512F-NEXT: popq %r14
; AVX512F-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-LABEL: cvt_4f64_to_8i16_zero:
[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
; AVX512VL: # %bb.0:
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: pushq %r14
; AVX512VL-NEXT: pushq %rbx
; AVX512VL-NEXT: subq $40, %rsp
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; AVX512VL-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
; AVX512VL-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512VL-NEXT: movl %eax, %ebx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shll $16, %ebx
; AVX512VL-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX512VL-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
; AVX512VL-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: movzwl %ax, %r14d
; AVX512VL-NEXT: orl %ebx, %r14d
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512VL-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vextractf128 $1, %ymm0, %xmm0
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512VL-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
; AVX512VL-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512VL-NEXT: movl %eax, %ebx
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shll $16, %ebx
; AVX512VL-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: movzwl %ax, %eax
; AVX512VL-NEXT: orl %ebx, %eax
; AVX512VL-NEXT: shlq $32, %rax
; AVX512VL-NEXT: orq %r14, %rax
; AVX512VL-NEXT: vmovq %rax, %xmm0
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: addq $40, %rsp
; AVX512VL-NEXT: popq %rbx
; AVX512VL-NEXT: popq %r14
; AVX512VL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <4 x double> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
%3 = shufflevector <4 x i16> %2, <4 x i16> zeroinitializer, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
ret <8 x i16> %3
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
}
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
define <8 x i16> @cvt_8f64_to_8i16(<8 x double> %a0) nounwind {
; AVX1-LABEL: cvt_8f64_to_8i16:
[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:
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: pushq %r15
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: subq $64, %rsp
; AVX1-NEXT: vmovups %ymm1, (%rsp) # 32-byte Spill
; AVX1-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %r15d
; AVX1-NEXT: orl %ebx, %r15d
[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: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %r14d
; AVX1-NEXT: orl %ebx, %r14d
; AVX1-NEXT: shlq $32, %r14
; AVX1-NEXT: orq %r15, %r14
[X86] Allow folding of stack reloads when loading a subreg of the spilled reg We did not support subregs in InlineSpiller:foldMemoryOperand() because targets may not deal with them correctly. This adds a target hook to let the spiller know that a target can handle subregs, and actually enables it for x86 for the case of stack slot reloads. This fixes PR30832. Differential Revision: https://reviews.llvm.org/D26521 llvm-svn: 287792
2016-11-24 02:33:49 +08:00
; AVX1-NEXT: vpermilpd $1, (%rsp), %xmm0 # 16-byte Folded Reload
; AVX1-NEXT: # xmm0 = mem[1,0]
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %r15d
; AVX1-NEXT: orl %ebx, %r15d
[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: vmovups (%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebx
; AVX1-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %eax
; AVX1-NEXT: orl %ebx, %eax
; AVX1-NEXT: shlq $32, %rax
; AVX1-NEXT: orq %r15, %rax
; AVX1-NEXT: vmovq %rax, %xmm0
; AVX1-NEXT: vmovq %r14, %xmm1
; AVX1-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX1-NEXT: addq $64, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: popq %r15
; AVX1-NEXT: retq
;
; AVX2-LABEL: cvt_8f64_to_8i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: pushq %r15
; AVX2-NEXT: pushq %r14
; AVX2-NEXT: pushq %rbx
; AVX2-NEXT: subq $64, %rsp
; AVX2-NEXT: vmovups %ymm1, (%rsp) # 32-byte Spill
; AVX2-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %r15d
; AVX2-NEXT: orl %ebx, %r15d
; AVX2-NEXT: vmovupd {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %r14d
; AVX2-NEXT: orl %ebx, %r14d
; AVX2-NEXT: shlq $32, %r14
; AVX2-NEXT: orq %r15, %r14
[X86] Allow folding of stack reloads when loading a subreg of the spilled reg We did not support subregs in InlineSpiller:foldMemoryOperand() because targets may not deal with them correctly. This adds a target hook to let the spiller know that a target can handle subregs, and actually enables it for x86 for the case of stack slot reloads. This fixes PR30832. Differential Revision: https://reviews.llvm.org/D26521 llvm-svn: 287792
2016-11-24 02:33:49 +08:00
; AVX2-NEXT: vpermilpd $1, (%rsp), %xmm0 # 16-byte Folded Reload
; AVX2-NEXT: # xmm0 = mem[1,0]
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %r15d
; AVX2-NEXT: orl %ebx, %r15d
; AVX2-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebx
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebx
; AVX2-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %eax
; AVX2-NEXT: orl %ebx, %eax
; AVX2-NEXT: shlq $32, %rax
; AVX2-NEXT: orq %r15, %rax
; AVX2-NEXT: vmovq %rax, %xmm0
; AVX2-NEXT: vmovq %r14, %xmm1
; AVX2-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX2-NEXT: addq $64, %rsp
; AVX2-NEXT: popq %rbx
; AVX2-NEXT: popq %r14
; AVX2-NEXT: popq %r15
; AVX2-NEXT: retq
;
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-LABEL: cvt_8f64_to_8i16:
[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:
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: pushq %r15
; AVX512-NEXT: pushq %r14
; AVX512-NEXT: pushq %rbx
; AVX512-NEXT: subq $96, %rsp
; AVX512-NEXT: vmovupd %zmm0, (%rsp) # 64-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512-NEXT: movl %eax, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovups (%rsp), %zmm0 # 64-byte Reload
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 $zmm0
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movzwl %ax, %r15d
; AVX512-NEXT: orl %ebx, %r15d
; AVX512-NEXT: vmovupd (%rsp), %zmm0 # 64-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512-NEXT: movl %eax, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movzwl %ax, %r14d
; AVX512-NEXT: orl %ebx, %r14d
; AVX512-NEXT: shlq $32, %r14
; AVX512-NEXT: orq %r15, %r14
; AVX512-NEXT: vmovupd (%rsp), %zmm0 # 64-byte Reload
; AVX512-NEXT: vextractf64x4 $1, %zmm0, %ymm0
; AVX512-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512-NEXT: movl %eax, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movzwl %ax, %r15d
; AVX512-NEXT: orl %ebx, %r15d
; AVX512-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512-NEXT: movl %eax, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: shll $16, %ebx
; AVX512-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movzwl %ax, %eax
; AVX512-NEXT: orl %ebx, %eax
; AVX512-NEXT: shlq $32, %rax
; AVX512-NEXT: orq %r15, %rax
; AVX512-NEXT: vmovq %rax, %xmm0
; AVX512-NEXT: vmovq %r14, %xmm1
; AVX512-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX512-NEXT: addq $96, %rsp
; AVX512-NEXT: popq %rbx
; AVX512-NEXT: popq %r14
; AVX512-NEXT: popq %r15
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <8 x double> %a0 to <8 x half>
%2 = bitcast <8 x half> %1 to <8 x i16>
ret <8 x i16> %2
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
}
;
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; Double to Half (Store)
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
;
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_f64_to_i16(double %a0, i16* %a1) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; ALL-LABEL: store_cvt_f64_to_i16:
[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
; ALL: # %bb.0:
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; ALL-NEXT: pushq %rbx
; ALL-NEXT: movq %rdi, %rbx
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; ALL-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; ALL-NEXT: movw %ax, (%rbx)
; ALL-NEXT: popq %rbx
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc double %a0 to half
%2 = bitcast half %1 to i16
store i16 %2, i16* %a1
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_2f64_to_2i16(<2 x double> %a0, <2 x i16>* %a1) nounwind {
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-LABEL: store_cvt_2f64_to_2i16:
[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
; ALL: # %bb.0:
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-NEXT: pushq %rbp
; ALL-NEXT: pushq %rbx
; ALL-NEXT: subq $24, %rsp
; ALL-NEXT: movq %rdi, %rbx
; ALL-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; ALL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; ALL-NEXT: callq __truncdfhf2
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-NEXT: movl %eax, %ebp
; ALL-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; ALL-NEXT: callq __truncdfhf2
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; ALL-NEXT: movw %ax, (%rbx)
; ALL-NEXT: movw %bp, 2(%rbx)
; ALL-NEXT: addq $24, %rsp
; ALL-NEXT: popq %rbx
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <2 x double> %a0 to <2 x half>
%2 = bitcast <2 x half> %1 to <2 x i16>
store <2 x i16> %2, <2 x i16>* %a1
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_4f64_to_4i16(<4 x double> %a0, <4 x i16>* %a1) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: store_cvt_4f64_to_4i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: pushq %rbp
; AVX1-NEXT: pushq %r15
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $88, %rsp
; AVX1-NEXT: movq %rdi, %rbx
; AVX1-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %r14d
[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: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %r15d
; AVX1-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %ebp
; AVX1-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movw %ax, 4(%rbx)
; AVX1-NEXT: movw %bp, (%rbx)
; AVX1-NEXT: movw %r15w, 6(%rbx)
; AVX1-NEXT: movw %r14w, 2(%rbx)
; AVX1-NEXT: addq $88, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: popq %r15
; AVX1-NEXT: popq %rbp
; AVX1-NEXT: retq
;
; AVX2-LABEL: store_cvt_4f64_to_4i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: pushq %rbp
; AVX2-NEXT: pushq %r15
; AVX2-NEXT: pushq %r14
; AVX2-NEXT: pushq %rbx
; AVX2-NEXT: subq $88, %rsp
; AVX2-NEXT: movq %rdi, %rbx
; AVX2-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %r14d
; AVX2-NEXT: vmovupd {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %r15d
; AVX2-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %ebp
; AVX2-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movw %ax, 4(%rbx)
; AVX2-NEXT: movw %bp, (%rbx)
; AVX2-NEXT: movw %r15w, 6(%rbx)
; AVX2-NEXT: movw %r14w, 2(%rbx)
; AVX2-NEXT: addq $88, %rsp
; AVX2-NEXT: popq %rbx
; AVX2-NEXT: popq %r14
; AVX2-NEXT: popq %r15
; AVX2-NEXT: popq %rbp
; AVX2-NEXT: retq
;
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-LABEL: store_cvt_4f64_to_4i16:
[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:
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: pushq %rbp
; AVX512-NEXT: pushq %r15
; AVX512-NEXT: pushq %r14
; AVX512-NEXT: pushq %rbx
; AVX512-NEXT: subq $88, %rsp
; AVX512-NEXT: movq %rdi, %rbx
; AVX512-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %r14d
; AVX512-NEXT: vmovupd {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %r15d
; AVX512-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %ebp
; AVX512-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movw %ax, 4(%rbx)
; AVX512-NEXT: movw %bp, (%rbx)
; AVX512-NEXT: movw %r15w, 6(%rbx)
; AVX512-NEXT: movw %r14w, 2(%rbx)
; AVX512-NEXT: addq $88, %rsp
; AVX512-NEXT: popq %rbx
; AVX512-NEXT: popq %r14
; AVX512-NEXT: popq %r15
; AVX512-NEXT: popq %rbp
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <4 x double> %a0 to <4 x half>
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
%2 = bitcast <4 x half> %1 to <4 x i16>
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
store <4 x i16> %2, <4 x i16>* %a1
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_4f64_to_8i16_undef(<4 x double> %a0, <8 x i16>* %a1) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: store_cvt_4f64_to_8i16_undef:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: pushq %rbp
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $32, %rsp
; AVX1-NEXT: movq %rdi, %r14
; AVX1-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebp
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebp
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %ebx
; AVX1-NEXT: orl %ebp, %ebx
[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: vmovups (%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX1-NEXT: movl %eax, %ebp
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: shll $16, %ebp
; AVX1-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movzwl %ax, %eax
; AVX1-NEXT: orl %ebp, %eax
; AVX1-NEXT: shlq $32, %rax
; AVX1-NEXT: orq %rbx, %rax
; AVX1-NEXT: vmovq %rax, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vmovdqa %xmm0, (%r14)
; AVX1-NEXT: addq $32, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: popq %rbp
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: retq
;
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-LABEL: store_cvt_4f64_to_8i16_undef:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: pushq %rbp
; AVX2-NEXT: pushq %r14
; AVX2-NEXT: pushq %rbx
; AVX2-NEXT: subq $32, %rsp
; AVX2-NEXT: movq %rdi, %r14
; AVX2-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebp
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebp
; AVX2-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %ebx
; AVX2-NEXT: orl %ebp, %ebx
; AVX2-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX2-NEXT: movl %eax, %ebp
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: shll $16, %ebp
; AVX2-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movzwl %ax, %eax
; AVX2-NEXT: orl %ebp, %eax
; AVX2-NEXT: shlq $32, %rax
; AVX2-NEXT: orq %rbx, %rax
; AVX2-NEXT: vmovq %rax, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX2-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vmovdqa %xmm0, (%r14)
; AVX2-NEXT: addq $32, %rsp
; AVX2-NEXT: popq %rbx
; AVX2-NEXT: popq %r14
; AVX2-NEXT: popq %rbp
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-LABEL: store_cvt_4f64_to_8i16_undef:
; AVX512: # %bb.0:
; AVX512-NEXT: pushq %rbp
; AVX512-NEXT: pushq %r14
; AVX512-NEXT: pushq %rbx
; AVX512-NEXT: subq $32, %rsp
; AVX512-NEXT: movq %rdi, %r14
; AVX512-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movl %eax, %ebp
; AVX512-NEXT: shll $16, %ebp
; AVX512-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movzwl %ax, %ebx
; AVX512-NEXT: orl %ebp, %ebx
; AVX512-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movl %eax, %ebp
; AVX512-NEXT: shll $16, %ebp
; AVX512-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512-NEXT: movzwl %ax, %eax
; AVX512-NEXT: orl %ebp, %eax
; AVX512-NEXT: shlq $32, %rax
; AVX512-NEXT: orq %rbx, %rax
; AVX512-NEXT: vmovq %rax, %xmm0
; AVX512-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX512-NEXT: vmovdqa %xmm0, (%r14)
; AVX512-NEXT: addq $32, %rsp
; AVX512-NEXT: popq %rbx
; AVX512-NEXT: popq %r14
; AVX512-NEXT: popq %rbp
; AVX512-NEXT: retq
%1 = fptrunc <4 x double> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
store <8 x i16> %3, <8 x i16>* %a1
ret void
}
define void @store_cvt_4f64_to_8i16_zero(<4 x double> %a0, <8 x i16>* %a1) nounwind {
; AVX1-LABEL: store_cvt_4f64_to_8i16_zero:
; AVX1: # %bb.0:
; AVX1-NEXT: pushq %rbp
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $32, %rsp
; AVX1-NEXT: movq %rdi, %r14
; AVX1-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movl %eax, %ebp
; AVX1-NEXT: shll $16, %ebp
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movzwl %ax, %ebx
; AVX1-NEXT: orl %ebp, %ebx
; AVX1-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movl %eax, %ebp
; AVX1-NEXT: shll $16, %ebp
; AVX1-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX1-NEXT: movzwl %ax, %eax
; AVX1-NEXT: orl %ebp, %eax
; AVX1-NEXT: shlq $32, %rax
; AVX1-NEXT: orq %rbx, %rax
; AVX1-NEXT: vmovq %rax, %xmm0
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX1-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
; AVX1-NEXT: vmovdqa %xmm0, (%r14)
; AVX1-NEXT: addq $32, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r14
; AVX1-NEXT: popq %rbp
; AVX1-NEXT: retq
;
; AVX2-SLOW-LABEL: store_cvt_4f64_to_8i16_zero:
; AVX2-SLOW: # %bb.0:
; AVX2-SLOW-NEXT: pushq %rbp
; AVX2-SLOW-NEXT: pushq %r14
; AVX2-SLOW-NEXT: pushq %rbx
; AVX2-SLOW-NEXT: subq $32, %rsp
; AVX2-SLOW-NEXT: movq %rdi, %r14
; AVX2-SLOW-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-SLOW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-SLOW-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movl %eax, %ebp
; AVX2-SLOW-NEXT: shll $16, %ebp
; AVX2-SLOW-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX2-SLOW-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX2-SLOW-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movzwl %ax, %ebx
; AVX2-SLOW-NEXT: orl %ebp, %ebx
; AVX2-SLOW-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-SLOW-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-SLOW-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-SLOW-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-SLOW-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movl %eax, %ebp
; AVX2-SLOW-NEXT: shll $16, %ebp
; AVX2-SLOW-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-SLOW-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-SLOW-NEXT: movzwl %ax, %eax
; AVX2-SLOW-NEXT: orl %ebp, %eax
; AVX2-SLOW-NEXT: shlq $32, %rax
; AVX2-SLOW-NEXT: orq %rbx, %rax
; AVX2-SLOW-NEXT: vmovq %rax, %xmm0
; AVX2-SLOW-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
; AVX2-SLOW-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
; AVX2-SLOW-NEXT: vmovdqa %xmm0, (%r14)
; AVX2-SLOW-NEXT: addq $32, %rsp
; AVX2-SLOW-NEXT: popq %rbx
; AVX2-SLOW-NEXT: popq %r14
; AVX2-SLOW-NEXT: popq %rbp
; AVX2-SLOW-NEXT: retq
;
; AVX2-FAST-LABEL: store_cvt_4f64_to_8i16_zero:
; AVX2-FAST: # %bb.0:
; AVX2-FAST-NEXT: pushq %rbp
; AVX2-FAST-NEXT: pushq %r14
; AVX2-FAST-NEXT: pushq %rbx
; AVX2-FAST-NEXT: subq $32, %rsp
; AVX2-FAST-NEXT: movq %rdi, %r14
; AVX2-FAST-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX2-FAST-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-FAST-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movl %eax, %ebp
; AVX2-FAST-NEXT: shll $16, %ebp
; AVX2-FAST-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
; AVX2-FAST-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
; AVX2-FAST-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movzwl %ax, %ebx
; AVX2-FAST-NEXT: orl %ebp, %ebx
; AVX2-FAST-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX2-FAST-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-FAST-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX2-FAST-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-FAST-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movl %eax, %ebp
; AVX2-FAST-NEXT: shll $16, %ebp
; AVX2-FAST-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-FAST-NEXT: callq __truncdfhf2
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX2-FAST-NEXT: movzwl %ax, %eax
; AVX2-FAST-NEXT: orl %ebp, %eax
; AVX2-FAST-NEXT: shlq $32, %rax
; AVX2-FAST-NEXT: orq %rbx, %rax
; AVX2-FAST-NEXT: vmovq %rax, %xmm0
; AVX2-FAST-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
; AVX2-FAST-NEXT: vmovdqa %xmm0, (%r14)
; AVX2-FAST-NEXT: addq $32, %rsp
; AVX2-FAST-NEXT: popq %rbx
; AVX2-FAST-NEXT: popq %r14
; AVX2-FAST-NEXT: popq %rbp
; AVX2-FAST-NEXT: retq
;
; AVX512F-LABEL: store_cvt_4f64_to_8i16_zero:
[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][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: pushq %rbp
; AVX512F-NEXT: pushq %r14
; AVX512F-NEXT: pushq %rbx
; AVX512F-NEXT: subq $32, %rsp
; AVX512F-NEXT: movq %rdi, %r14
; AVX512F-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512F-NEXT: movl %eax, %ebp
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shll $16, %ebp
; AVX512F-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movzwl %ax, %ebx
; AVX512F-NEXT: orl %ebp, %ebx
; AVX512F-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
; AVX512F-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512F-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
; AVX512F-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512F-NEXT: movl %eax, %ebp
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: shll $16, %ebp
; AVX512F-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512F-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: movzwl %ax, %eax
; AVX512F-NEXT: orl %ebp, %eax
; AVX512F-NEXT: shlq $32, %rax
; AVX512F-NEXT: orq %rbx, %rax
; AVX512F-NEXT: vmovq %rax, %xmm0
[X86][SSE] Propagate undef upper elements from scalar_to_vector during shuffle combining Only do this for integer types currently - floats types (in particular insertps) load folding often fails with this. llvm-svn: 295208
2017-02-16 01:41:33 +08:00
; AVX512F-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,2,2,3,4,5,6,7]
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512F-NEXT: vmovq {{.*#+}} xmm0 = xmm0[0],zero
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512F-NEXT: vmovdqa %xmm0, (%r14)
; AVX512F-NEXT: addq $32, %rsp
; AVX512F-NEXT: popq %rbx
; AVX512F-NEXT: popq %r14
; AVX512F-NEXT: popq %rbp
; AVX512F-NEXT: retq
;
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-LABEL: store_cvt_4f64_to_8i16_zero:
[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
; AVX512VL: # %bb.0:
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: pushq %rbp
; AVX512VL-NEXT: pushq %r14
; AVX512VL-NEXT: pushq %rbx
; AVX512VL-NEXT: subq $32, %rsp
; AVX512VL-NEXT: movq %rdi, %r14
[AVX-512] Correct ExeDomain for many AVX-512 instructions. llvm-svn: 277416
2016-08-02 13:11:15 +08:00
; AVX512VL-NEXT: vmovupd %ymm0, (%rsp) # 32-byte Spill
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
; AVX512VL-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512VL-NEXT: movl %eax, %ebp
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shll $16, %ebp
; AVX512VL-NEXT: vmovups (%rsp), %ymm0 # 32-byte Reload
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
; AVX512VL-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
; AVX512VL-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: movzwl %ax, %ebx
; AVX512VL-NEXT: orl %ebp, %ebx
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512VL-NEXT: vmovupd (%rsp), %ymm0 # 32-byte Reload
[AVX-512] Teach EVEX to VEX conversion pass to handle VINSERT and VEXTRACT instructions. llvm-svn: 290869
2017-01-03 13:46:18 +08:00
; AVX512VL-NEXT: vextractf128 $1, %ymm0, %xmm0
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512VL-NEXT: vmovapd %xmm0, (%rsp) # 16-byte Spill
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
[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
; AVX512VL-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86FixupBWInsts] More precise register liveness if no <imp-use> on MOVs. Summary: Subregister liveness tracking is not implemented for X86 backend, so sometimes the whole super register is said to be live, when only a subregister is really live. That might happen if the def and the use are located in different MBBs, see added fixup-bw-isnt.mir test. However, using knowledge of the specific instructions handled by the bw-fixup-pass we can get more precise liveness information which this change does. Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper Reviewed By: craig.topper Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D37559 llvm-svn: 313524
2017-09-18 18:17:59 +08:00
; AVX512VL-NEXT: movl %eax, %ebp
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: shll $16, %ebp
; AVX512VL-NEXT: vmovaps (%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512VL-NEXT: callq __truncdfhf2
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: movzwl %ax, %eax
; AVX512VL-NEXT: orl %ebp, %eax
; AVX512VL-NEXT: shlq $32, %rax
; AVX512VL-NEXT: orq %rbx, %rax
; AVX512VL-NEXT: vmovq %rax, %xmm0
[TargetLowering] Add vector BITCAST support to SimplifyDemandedVectorElts Notably helps cleanup after legalization of vector types Differential Revision: https://reviews.llvm.org/D43674 llvm-svn: 326838
2018-03-07 06:32:01 +08:00
; AVX512VL-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,4,5,4,5,6,7],zero,zero,zero,zero,zero,zero,zero,zero
This is a large patch for X86 AVX-512 of an optimization for reducing code size by encoding EVEX AVX-512 instructions using the shorter VEX encoding when possible. There are cases of AVX-512 instructions that have two possible encodings. This is the case with instructions that use vector registers with low indexes of 0 - 15 and do not use the zmm registers or the mask k registers. The EVEX encoding prefix requires 4 bytes whereas the VEX prefix can take only up to 3 bytes. Consequently, using the VEX encoding for these instructions results in a code size reduction of ~2 bytes even though it is compiled with the AVX-512 features enabled. Reviewers: Craig Topper, Zvi Rackoover, Elena Demikhovsky Differential Revision: https://reviews.llvm.org/D27901 llvm-svn: 290663
2016-12-28 18:12:48 +08:00
; AVX512VL-NEXT: vmovdqa %xmm0, (%r14)
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
; AVX512VL-NEXT: addq $32, %rsp
; AVX512VL-NEXT: popq %rbx
; AVX512VL-NEXT: popq %r14
; AVX512VL-NEXT: popq %rbp
; AVX512VL-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <4 x double> %a0 to <4 x half>
%2 = bitcast <4 x half> %1 to <4 x i16>
%3 = shufflevector <4 x i16> %2, <4 x i16> zeroinitializer, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
store <8 x i16> %3, <8 x i16>* %a1
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
ret void
}
[X86][AVX512VL] Added AVX512VL half2float vector conversions tests to demonstrate PR23941 llvm-svn: 276563
2016-07-24 21:01:51 +08:00
define void @store_cvt_8f64_to_8i16(<8 x double> %a0, <8 x i16>* %a1) nounwind {
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-LABEL: store_cvt_8f64_to_8i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: pushq %rbp
; AVX1-NEXT: pushq %r15
; AVX1-NEXT: pushq %r14
; AVX1-NEXT: pushq %r13
; AVX1-NEXT: pushq %r12
; AVX1-NEXT: pushq %rbx
; AVX1-NEXT: subq $136, %rsp
; AVX1-NEXT: movq %rdi, %rbx
; AVX1-NEXT: vmovups %ymm1, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX1-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movw %ax, {{[0-9]+}}(%rsp) # 2-byte Spill
[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: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movw %ax, {{[0-9]+}}(%rsp) # 2-byte Spill
[X86] Allow folding of stack reloads when loading a subreg of the spilled reg We did not support subregs in InlineSpiller:foldMemoryOperand() because targets may not deal with them correctly. This adds a target hook to let the spiller know that a target can handle subregs, and actually enables it for x86 for the case of stack slot reloads. This fixes PR30832. Differential Revision: https://reviews.llvm.org/D26521 llvm-svn: 287792
2016-11-24 02:33:49 +08:00
; AVX1-NEXT: vpermilpd $1, {{[0-9]+}}(%rsp), %xmm0 # 16-byte Folded Reload
; AVX1-NEXT: # xmm0 = mem[1,0]
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %r12d
[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: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX1-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %r13d
; AVX1-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %ebp
; AVX1-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %r14d
; AVX1-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX1-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movl %eax, %r15d
; AVX1-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX1-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX1-NEXT: movw %ax, 12(%rbx)
; AVX1-NEXT: movw %r15w, 8(%rbx)
; AVX1-NEXT: movw %r14w, 4(%rbx)
; AVX1-NEXT: movw %bp, (%rbx)
; AVX1-NEXT: movw %r13w, 14(%rbx)
; AVX1-NEXT: movw %r12w, 10(%rbx)
; AVX1-NEXT: movzwl {{[0-9]+}}(%rsp), %eax # 2-byte Folded Reload
; AVX1-NEXT: movw %ax, 6(%rbx)
; AVX1-NEXT: movzwl {{[0-9]+}}(%rsp), %eax # 2-byte Folded Reload
; AVX1-NEXT: movw %ax, 2(%rbx)
; AVX1-NEXT: addq $136, %rsp
; AVX1-NEXT: popq %rbx
; AVX1-NEXT: popq %r12
; AVX1-NEXT: popq %r13
; AVX1-NEXT: popq %r14
; AVX1-NEXT: popq %r15
; AVX1-NEXT: popq %rbp
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX1-NEXT: retq
;
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-LABEL: store_cvt_8f64_to_8i16:
[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][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: pushq %rbp
; AVX2-NEXT: pushq %r15
; AVX2-NEXT: pushq %r14
; AVX2-NEXT: pushq %r13
; AVX2-NEXT: pushq %r12
; AVX2-NEXT: pushq %rbx
; AVX2-NEXT: subq $136, %rsp
; AVX2-NEXT: movq %rdi, %rbx
; AVX2-NEXT: vmovups %ymm1, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX2-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movw %ax, {{[0-9]+}}(%rsp) # 2-byte Spill
; AVX2-NEXT: vmovupd {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movw %ax, {{[0-9]+}}(%rsp) # 2-byte Spill
[X86] Allow folding of stack reloads when loading a subreg of the spilled reg We did not support subregs in InlineSpiller:foldMemoryOperand() because targets may not deal with them correctly. This adds a target hook to let the spiller know that a target can handle subregs, and actually enables it for x86 for the case of stack slot reloads. This fixes PR30832. Differential Revision: https://reviews.llvm.org/D26521 llvm-svn: 287792
2016-11-24 02:33:49 +08:00
; AVX2-NEXT: vpermilpd $1, {{[0-9]+}}(%rsp), %xmm0 # 16-byte Folded Reload
; AVX2-NEXT: # xmm0 = mem[1,0]
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %r12d
; AVX2-NEXT: vmovupd {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
; AVX2-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX2-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX2-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %r13d
; AVX2-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %ebp
; AVX2-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %r14d
; AVX2-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
; AVX2-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movl %eax, %r15d
; AVX2-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX2-NEXT: callq __truncdfhf2
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
; AVX2-NEXT: movw %ax, 12(%rbx)
; AVX2-NEXT: movw %r15w, 8(%rbx)
; AVX2-NEXT: movw %r14w, 4(%rbx)
; AVX2-NEXT: movw %bp, (%rbx)
; AVX2-NEXT: movw %r13w, 14(%rbx)
; AVX2-NEXT: movw %r12w, 10(%rbx)
; AVX2-NEXT: movzwl {{[0-9]+}}(%rsp), %eax # 2-byte Folded Reload
; AVX2-NEXT: movw %ax, 6(%rbx)
; AVX2-NEXT: movzwl {{[0-9]+}}(%rsp), %eax # 2-byte Folded Reload
; AVX2-NEXT: movw %ax, 2(%rbx)
; AVX2-NEXT: addq $136, %rsp
; AVX2-NEXT: popq %rbx
; AVX2-NEXT: popq %r12
; AVX2-NEXT: popq %r13
; AVX2-NEXT: popq %r14
; AVX2-NEXT: popq %r15
; AVX2-NEXT: popq %rbp
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
; AVX2-NEXT: retq
;
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-LABEL: store_cvt_8f64_to_8i16:
[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:
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: pushq %rbp
; AVX512-NEXT: pushq %r15
; AVX512-NEXT: pushq %r14
; AVX512-NEXT: pushq %r13
; AVX512-NEXT: pushq %r12
; AVX512-NEXT: pushq %rbx
; AVX512-NEXT: subq $200, %rsp
; AVX512-NEXT: movq %rdi, %rbx
; AVX512-NEXT: vmovupd %zmm0, {{[0-9]+}}(%rsp) # 64-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movw %ax, {{[0-9]+}}(%rsp) # 2-byte Spill
; AVX512-NEXT: vmovupd {{[0-9]+}}(%rsp), %zmm0 # 64-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movw %ax, {{[0-9]+}}(%rsp) # 2-byte Spill
; AVX512-NEXT: vmovupd {{[0-9]+}}(%rsp), %zmm0 # 64-byte Reload
; AVX512-NEXT: vextractf64x4 $1, %zmm0, %ymm0
; AVX512-NEXT: vmovupd %ymm0, {{[0-9]+}}(%rsp) # 32-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %r12d
; AVX512-NEXT: vmovupd {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
; AVX512-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX512-NEXT: vmovapd %xmm0, {{[0-9]+}}(%rsp) # 16-byte Spill
; AVX512-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %r13d
; AVX512-NEXT: vmovups {{[0-9]+}}(%rsp), %zmm0 # 64-byte Reload
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 $zmm0
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %ebp
; AVX512-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %r14d
; AVX512-NEXT: vmovups {{[0-9]+}}(%rsp), %ymm0 # 32-byte Reload
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
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: vzeroupper
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movl %eax, %r15d
; AVX512-NEXT: vmovaps {{[0-9]+}}(%rsp), %xmm0 # 16-byte Reload
Go back to sometimes assuming intristics are local. This fixes pr36674. While it is valid for shouldAssumeDSOLocal to return false anytime, always returning false for intrinsics is not optimal on i386 and also hits a bug in the backend. To use a plt, the caller must first setup ebx to handle the case of that file being linked into a PIE executable or shared library. In those cases the generated PLT uses ebx. Currently we can produce "calll expf@plt" without setting ebx. We could fix that by correctly setting ebx, but this would produce worse code for the case where the runtime library is statically linked. It would also required other tools to handle R_386_PLT32. llvm-svn: 327198
2018-03-10 10:42:14 +08:00
; AVX512-NEXT: callq __truncdfhf2
[AVX-512] Add unmasked subvector inserts and extract to the execution domain tables. llvm-svn: 309632
2017-08-01 06:07:29 +08:00
; AVX512-NEXT: movw %ax, 12(%rbx)
; AVX512-NEXT: movw %r15w, 8(%rbx)
; AVX512-NEXT: movw %r14w, 4(%rbx)
; AVX512-NEXT: movw %bp, (%rbx)
; AVX512-NEXT: movw %r13w, 14(%rbx)
; AVX512-NEXT: movw %r12w, 10(%rbx)
; AVX512-NEXT: movzwl {{[0-9]+}}(%rsp), %eax # 2-byte Folded Reload
; AVX512-NEXT: movw %ax, 6(%rbx)
; AVX512-NEXT: movzwl {{[0-9]+}}(%rsp), %eax # 2-byte Folded Reload
; AVX512-NEXT: movw %ax, 2(%rbx)
; AVX512-NEXT: addq $200, %rsp
; AVX512-NEXT: popq %rbx
; AVX512-NEXT: popq %r12
; AVX512-NEXT: popq %r13
; AVX512-NEXT: popq %r14
; AVX512-NEXT: popq %r15
; AVX512-NEXT: popq %rbp
; AVX512-NEXT: retq
[X86][F16C] Added half <-> double conversion tests llvm-svn: 273153
2016-06-20 20:51:55 +08:00
%1 = fptrunc <8 x double> %a0 to <8 x half>
%2 = bitcast <8 x half> %1 to <8 x i16>
store <8 x i16> %2, <8 x i16>* %a1
[X86][F16C] Added native IR half/float conversion tests. Placeholder tests until we start improving native vector support. llvm-svn: 261989
2016-02-26 16:52:29 +08:00
ret void
}