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/i64-to-float.ll

285 lines
11 KiB
LLVM
Raw Normal View History

[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=i686-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X32-SSE
; RUN: llc < %s -mtriple=i686-unknown -mattr=+avx | FileCheck %s --check-prefix=X32-AVX
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64-SSE
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+avx | FileCheck %s --check-prefix=X64-AVX
;PR29078
define <2 x double> @mask_sitofp_2i64_2f64(<2 x i64> %a) nounwind {
; X32-SSE-LABEL: mask_sitofp_2i64_2f64:
; X32-SSE: # BB#0:
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X32-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-SSE-NEXT: pand {{\.LCPI.*}}, %xmm0
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X32-SSE-NEXT: cvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-SSE-NEXT: retl
;
; X32-AVX-LABEL: mask_sitofp_2i64_2f64:
; X32-AVX: # BB#0:
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X32-AVX-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0],zero,zero,zero,xmm0[8,9],zero,zero,xmm0[u,u,u,u,u,u,u,u]
; X32-AVX-NEXT: vcvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-AVX-NEXT: retl
;
; X64-SSE-LABEL: mask_sitofp_2i64_2f64:
; X64-SSE: # BB#0:
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X64-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: pand {{.*}}(%rip), %xmm0
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X64-SSE-NEXT: cvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: retq
;
; X64-AVX-LABEL: mask_sitofp_2i64_2f64:
; X64-AVX: # BB#0:
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X64-AVX-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0],zero,zero,zero,xmm0[8,9],zero,zero,xmm0[u,u,u,u,u,u,u,u]
; X64-AVX-NEXT: vcvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-AVX-NEXT: retq
%and = and <2 x i64> %a, <i64 255, i64 65535>
%cvt = sitofp <2 x i64> %and to <2 x double>
ret <2 x double> %cvt
}
define <2 x double> @mask_uitofp_2i64_2f64(<2 x i64> %a) nounwind {
; X32-SSE-LABEL: mask_uitofp_2i64_2f64:
; X32-SSE: # BB#0:
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X32-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-SSE-NEXT: pand {{\.LCPI.*}}, %xmm0
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X32-SSE-NEXT: cvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-SSE-NEXT: retl
;
; X32-AVX-LABEL: mask_uitofp_2i64_2f64:
; X32-AVX: # BB#0:
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X32-AVX-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0],zero,zero,zero,xmm0[8,9],zero,zero,xmm0[u,u,u,u,u,u,u,u]
; X32-AVX-NEXT: vcvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-AVX-NEXT: retl
;
; X64-SSE-LABEL: mask_uitofp_2i64_2f64:
; X64-SSE: # BB#0:
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X64-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm0[0,2,2,3]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: pand {{.*}}(%rip), %xmm0
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X64-SSE-NEXT: cvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: retq
;
; X64-AVX-LABEL: mask_uitofp_2i64_2f64:
; X64-AVX: # BB#0:
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X64-AVX-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0],zero,zero,zero,xmm0[8,9],zero,zero,xmm0[u,u,u,u,u,u,u,u]
; X64-AVX-NEXT: vcvtdq2pd %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-AVX-NEXT: retq
%and = and <2 x i64> %a, <i64 255, i64 65535>
%cvt = uitofp <2 x i64> %and to <2 x double>
ret <2 x double> %cvt
}
define <4 x float> @mask_sitofp_4i64_4f32(<4 x i64> %a) nounwind {
; X32-SSE-LABEL: mask_sitofp_4i64_4f32:
; X32-SSE: # BB#0:
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X32-SSE-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X32-SSE-NEXT: andps {{\.LCPI.*}}, %xmm0
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X32-SSE-NEXT: cvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-SSE-NEXT: retl
;
; X32-AVX-LABEL: mask_sitofp_4i64_4f32:
; X32-AVX: # BB#0:
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X32-AVX-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X32-AVX-NEXT: vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X32-AVX-NEXT: vandps {{\.LCPI.*}}, %xmm0, %xmm0
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X32-AVX-NEXT: vcvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-AVX-NEXT: vzeroupper
; X32-AVX-NEXT: retl
;
; X64-SSE-LABEL: mask_sitofp_4i64_4f32:
; X64-SSE: # BB#0:
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X64-SSE-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X64-SSE-NEXT: andps {{.*}}(%rip), %xmm0
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X64-SSE-NEXT: cvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: retq
;
; X64-AVX-LABEL: mask_sitofp_4i64_4f32:
; X64-AVX: # BB#0:
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X64-AVX-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X64-AVX-NEXT: vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X64-AVX-NEXT: vandps {{.*}}(%rip), %xmm0, %xmm0
[X86][SSE] Improve recognition of i64 sitofp conversions that can be performed as i32 (PR29078) Until AVX512DQ we only support i64/vXi64 sitofp conversion as scalars. This patch sees if the sign bit extends far enough that we can truncate to a i32 type and then perform sitofp without loss of precision. Differential Revision: https://reviews.llvm.org/D24345 llvm-svn: 281502
2016-09-15 01:15:26 +08:00
; X64-AVX-NEXT: vcvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-AVX-NEXT: vzeroupper
; X64-AVX-NEXT: retq
%and = and <4 x i64> %a, <i64 127, i64 255, i64 4095, i64 65535>
%cvt = sitofp <4 x i64> %and to <4 x float>
ret <4 x float> %cvt
}
define <4 x float> @mask_uitofp_4i64_4f32(<4 x i64> %a) nounwind {
; X32-SSE-LABEL: mask_uitofp_4i64_4f32:
; X32-SSE: # BB#0:
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X32-SSE-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X32-SSE-NEXT: andps {{\.LCPI.*}}, %xmm0
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X32-SSE-NEXT: cvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-SSE-NEXT: retl
;
; X32-AVX-LABEL: mask_uitofp_4i64_4f32:
; X32-AVX: # BB#0:
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X32-AVX-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X32-AVX-NEXT: vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X32-AVX-NEXT: vandps {{\.LCPI.*}}, %xmm0, %xmm0
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X32-AVX-NEXT: vcvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-AVX-NEXT: vzeroupper
; X32-AVX-NEXT: retl
;
; X64-SSE-LABEL: mask_uitofp_4i64_4f32:
; X64-SSE: # BB#0:
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X64-SSE-NEXT: shufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X64-SSE-NEXT: andps {{.*}}(%rip), %xmm0
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X64-SSE-NEXT: cvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: retq
;
; X64-AVX-LABEL: mask_uitofp_4i64_4f32:
; X64-AVX: # BB#0:
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X64-AVX-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] use a single shufps when it can save instructions This is a tiny patch with a big pile of test changes. This partially fixes PR27885: https://llvm.org/bugs/show_bug.cgi?id=27885 My motivating case looks like this: - vpshufd {{.*#+}} xmm1 = xmm1[0,1,0,2] - vpshufd {{.*#+}} xmm0 = xmm0[0,2,2,3] - vpblendw {{.*#+}} xmm0 = xmm0[0,1,2,3],xmm1[4,5,6,7] + vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2] And this happens several times in the diffs. For chips with domain-crossing penalties, the instruction count and size reduction should usually overcome any potential domain-crossing penalty due to using an FP op in a sequence of int ops. For chips such as recent Intel big cores and Atom, there is no domain-crossing penalty for shufps, so using shufps is a pure win. So the test case diffs all appear to be improvements except one test in vector-shuffle-combining.ll where we miss an opportunity to use a shift to generate zero elements and one test in combine-sra.ll where multiple uses prevent the expected shuffle combining. Differential Revision: https://reviews.llvm.org/D27692 llvm-svn: 289837
2016-12-16 02:03:38 +08:00
; X64-AVX-NEXT: vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,2]
[X86] Attempt to pre-truncate arithmetic operations if useful In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types. This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold). Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs. I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need. Differential Revision: https://reviews.llvm.org/D28219 llvm-svn: 290947
2017-01-04 16:05:42 +08:00
; X64-AVX-NEXT: vandps {{.*}}(%rip), %xmm0, %xmm0
[X86][SSE] Improve recognition of uitofp conversions that can be performed as sitofp With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations. This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware). While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions. Differential Revision: https://reviews.llvm.org/D24343 llvm-svn: 281852
2016-09-18 20:45:23 +08:00
; X64-AVX-NEXT: vcvtdq2ps %xmm0, %xmm0
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-AVX-NEXT: vzeroupper
; X64-AVX-NEXT: retq
%and = and <4 x i64> %a, <i64 127, i64 255, i64 4095, i64 65535>
%cvt = uitofp <4 x i64> %and to <4 x float>
ret <4 x float> %cvt
}
define <2 x double> @clamp_sitofp_2i64_2f64(<2 x i64> %a) nounwind {
; X32-SSE-LABEL: clamp_sitofp_2i64_2f64:
; X32-SSE: # BB#0:
; X32-SSE-NEXT: pushl %ebp
; X32-SSE-NEXT: movl %esp, %ebp
; X32-SSE-NEXT: andl $-8, %esp
; X32-SSE-NEXT: subl $32, %esp
; X32-SSE-NEXT: movdqa {{.*#+}} xmm1 = [2147483648,0,2147483648,0]
; X32-SSE-NEXT: movdqa %xmm0, %xmm2
; X32-SSE-NEXT: pxor %xmm1, %xmm2
; X32-SSE-NEXT: movdqa {{.*#+}} xmm3 = [2147483393,4294967295,2147483393,4294967295]
; X32-SSE-NEXT: movdqa %xmm3, %xmm4
; X32-SSE-NEXT: pcmpgtd %xmm2, %xmm4
; X32-SSE-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
; X32-SSE-NEXT: pcmpeqd %xmm3, %xmm2
; X32-SSE-NEXT: pshufd {{.*#+}} xmm2 = xmm2[1,1,3,3]
; X32-SSE-NEXT: pand %xmm5, %xmm2
; X32-SSE-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
; X32-SSE-NEXT: por %xmm2, %xmm3
; X32-SSE-NEXT: movdqa %xmm3, %xmm2
; X32-SSE-NEXT: pandn %xmm0, %xmm2
; X32-SSE-NEXT: pand {{\.LCPI.*}}, %xmm3
; X32-SSE-NEXT: por %xmm2, %xmm3
; X32-SSE-NEXT: pxor %xmm3, %xmm1
; X32-SSE-NEXT: movdqa {{.*#+}} xmm0 = [2147483903,0,2147483903,0]
; X32-SSE-NEXT: movdqa %xmm1, %xmm2
; X32-SSE-NEXT: pcmpgtd %xmm0, %xmm2
; X32-SSE-NEXT: pshufd {{.*#+}} xmm4 = xmm2[0,0,2,2]
; X32-SSE-NEXT: pcmpeqd %xmm0, %xmm1
; X32-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
; X32-SSE-NEXT: pand %xmm4, %xmm0
; X32-SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
; X32-SSE-NEXT: por %xmm0, %xmm1
; X32-SSE-NEXT: movdqa %xmm1, %xmm0
; X32-SSE-NEXT: pandn %xmm3, %xmm0
; X32-SSE-NEXT: pand {{\.LCPI.*}}, %xmm1
; X32-SSE-NEXT: por %xmm0, %xmm1
; X32-SSE-NEXT: movq {{.*#+}} xmm0 = xmm1[0],zero
; X32-SSE-NEXT: movq %xmm0, {{[0-9]+}}(%esp)
; X32-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; X32-SSE-NEXT: movq %xmm0, {{[0-9]+}}(%esp)
; X32-SSE-NEXT: fildll {{[0-9]+}}(%esp)
; X32-SSE-NEXT: fstpl {{[0-9]+}}(%esp)
; X32-SSE-NEXT: fildll {{[0-9]+}}(%esp)
; X32-SSE-NEXT: fstpl (%esp)
; X32-SSE-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; X32-SSE-NEXT: movhpd {{.*#+}} xmm0 = xmm0[0],mem[0]
; X32-SSE-NEXT: movl %ebp, %esp
; X32-SSE-NEXT: popl %ebp
; X32-SSE-NEXT: retl
;
; X32-AVX-LABEL: clamp_sitofp_2i64_2f64:
; X32-AVX: # BB#0:
; X32-AVX-NEXT: pushl %ebp
; X32-AVX-NEXT: movl %esp, %ebp
; X32-AVX-NEXT: andl $-8, %esp
; X32-AVX-NEXT: subl $32, %esp
; X32-AVX-NEXT: vmovdqa {{.*#+}} xmm1 = [4294967041,4294967295,4294967041,4294967295]
; X32-AVX-NEXT: vpcmpgtq %xmm0, %xmm1, %xmm2
; X32-AVX-NEXT: vblendvpd %xmm2, %xmm1, %xmm0, %xmm0
; X32-AVX-NEXT: vmovdqa {{.*#+}} xmm1 = [255,0,255,0]
; X32-AVX-NEXT: vpcmpgtq %xmm1, %xmm0, %xmm2
; X32-AVX-NEXT: vblendvpd %xmm2, %xmm1, %xmm0, %xmm0
; X32-AVX-NEXT: vmovq {{.*#+}} xmm1 = xmm0[0],zero
; X32-AVX-NEXT: vmovq %xmm1, {{[0-9]+}}(%esp)
[X86] Teach execution domain fixing to convert between VPERMILPS and VPSHUFD. llvm-svn: 313507
2017-09-18 11:29:47 +08:00
; X32-AVX-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[2,3,0,1]
; X32-AVX-NEXT: vmovlpd %xmm0, {{[0-9]+}}(%esp)
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X32-AVX-NEXT: fildll {{[0-9]+}}(%esp)
; X32-AVX-NEXT: fstpl {{[0-9]+}}(%esp)
; X32-AVX-NEXT: fildll {{[0-9]+}}(%esp)
; X32-AVX-NEXT: fstpl (%esp)
; X32-AVX-NEXT: vmovsd {{.*#+}} xmm0 = mem[0],zero
; X32-AVX-NEXT: vmovhpd {{.*#+}} xmm0 = xmm0[0],mem[0]
; X32-AVX-NEXT: movl %ebp, %esp
; X32-AVX-NEXT: popl %ebp
; X32-AVX-NEXT: retl
;
; X64-SSE-LABEL: clamp_sitofp_2i64_2f64:
; X64-SSE: # BB#0:
; X64-SSE-NEXT: movdqa {{.*#+}} xmm1 = [2147483648,0,2147483648,0]
; X64-SSE-NEXT: movdqa %xmm0, %xmm2
; X64-SSE-NEXT: pxor %xmm1, %xmm2
[DAG] add splat vector support for 'xor' in SimplifyDemandedBits This allows forming more 'not' ops, so we get improvements for ISAs that have and-not. Follow-up to: https://reviews.llvm.org/rL300725 llvm-svn: 300763
2017-04-20 05:23:09 +08:00
; X64-SSE-NEXT: movdqa {{.*#+}} xmm3 = [18446744071562067713,18446744071562067713]
; X64-SSE-NEXT: movdqa %xmm3, %xmm4
; X64-SSE-NEXT: pcmpgtd %xmm2, %xmm4
; X64-SSE-NEXT: pshufd {{.*#+}} xmm5 = xmm4[0,0,2,2]
; X64-SSE-NEXT: pcmpeqd %xmm3, %xmm2
; X64-SSE-NEXT: pshufd {{.*#+}} xmm2 = xmm2[1,1,3,3]
; X64-SSE-NEXT: pand %xmm5, %xmm2
; X64-SSE-NEXT: pshufd {{.*#+}} xmm3 = xmm4[1,1,3,3]
; X64-SSE-NEXT: por %xmm2, %xmm3
; X64-SSE-NEXT: movdqa %xmm3, %xmm2
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: pandn %xmm0, %xmm2
[DAG] add splat vector support for 'xor' in SimplifyDemandedBits This allows forming more 'not' ops, so we get improvements for ISAs that have and-not. Follow-up to: https://reviews.llvm.org/rL300725 llvm-svn: 300763
2017-04-20 05:23:09 +08:00
; X64-SSE-NEXT: pand {{.*}}(%rip), %xmm3
; X64-SSE-NEXT: por %xmm2, %xmm3
[DAG] add splat vector support for 'or' in SimplifyDemandedBits I've changed one of the tests to not fold away, but we didn't and still don't do the transform that the comment claims we do (and I don't know why we'd want to do that). Follow-up to: https://reviews.llvm.org/rL300725 https://reviews.llvm.org/rL300763 llvm-svn: 300772
2017-04-20 06:00:00 +08:00
; X64-SSE-NEXT: pxor %xmm3, %xmm1
; X64-SSE-NEXT: movdqa {{.*#+}} xmm0 = [2147483903,2147483903]
; X64-SSE-NEXT: movdqa %xmm1, %xmm2
; X64-SSE-NEXT: pcmpgtd %xmm0, %xmm2
; X64-SSE-NEXT: pshufd {{.*#+}} xmm4 = xmm2[0,0,2,2]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: pcmpeqd %xmm0, %xmm1
; X64-SSE-NEXT: pshufd {{.*#+}} xmm0 = xmm1[1,1,3,3]
[DAG] add splat vector support for 'or' in SimplifyDemandedBits I've changed one of the tests to not fold away, but we didn't and still don't do the transform that the comment claims we do (and I don't know why we'd want to do that). Follow-up to: https://reviews.llvm.org/rL300725 https://reviews.llvm.org/rL300763 llvm-svn: 300772
2017-04-20 06:00:00 +08:00
; X64-SSE-NEXT: pand %xmm4, %xmm0
; X64-SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm2[1,1,3,3]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: por %xmm0, %xmm1
; X64-SSE-NEXT: movdqa %xmm1, %xmm0
[DAG] add splat vector support for 'xor' in SimplifyDemandedBits This allows forming more 'not' ops, so we get improvements for ISAs that have and-not. Follow-up to: https://reviews.llvm.org/rL300725 llvm-svn: 300763
2017-04-20 05:23:09 +08:00
; X64-SSE-NEXT: pandn %xmm3, %xmm0
[DAG] add splat vector support for 'or' in SimplifyDemandedBits I've changed one of the tests to not fold away, but we didn't and still don't do the transform that the comment claims we do (and I don't know why we'd want to do that). Follow-up to: https://reviews.llvm.org/rL300725 https://reviews.llvm.org/rL300763 llvm-svn: 300772
2017-04-20 06:00:00 +08:00
; X64-SSE-NEXT: pand {{.*}}(%rip), %xmm1
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: por %xmm0, %xmm1
[X86][SSE2] Fix asm string for movq (Move Quadword) instruction. Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
2017-04-26 15:08:44 +08:00
; X64-SSE-NEXT: movq %xmm1, %rax
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: xorps %xmm0, %xmm0
; X64-SSE-NEXT: cvtsi2sdq %rax, %xmm0
; X64-SSE-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[X86][SSE2] Fix asm string for movq (Move Quadword) instruction. Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
2017-04-26 15:08:44 +08:00
; X64-SSE-NEXT: movq %xmm1, %rax
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: xorps %xmm1, %xmm1
; X64-SSE-NEXT: cvtsi2sdq %rax, %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
; X64-SSE-NEXT: movlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-SSE-NEXT: retq
;
; X64-AVX-LABEL: clamp_sitofp_2i64_2f64:
; X64-AVX: # BB#0:
; X64-AVX-NEXT: vmovdqa {{.*#+}} xmm1 = [18446744073709551361,18446744073709551361]
; X64-AVX-NEXT: vpcmpgtq %xmm0, %xmm1, %xmm2
; X64-AVX-NEXT: vblendvpd %xmm2, %xmm1, %xmm0, %xmm0
; X64-AVX-NEXT: vmovdqa {{.*#+}} xmm1 = [255,255]
; X64-AVX-NEXT: vpcmpgtq %xmm1, %xmm0, %xmm2
; X64-AVX-NEXT: vblendvpd %xmm2, %xmm1, %xmm0, %xmm0
; X64-AVX-NEXT: vpextrq $1, %xmm0, %rax
; X64-AVX-NEXT: vcvtsi2sdq %rax, %xmm3, %xmm1
; X64-AVX-NEXT: vmovq %xmm0, %rax
; X64-AVX-NEXT: vcvtsi2sdq %rax, %xmm3, %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
; X64-AVX-NEXT: vmovlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
[X86][SSE] Add test cases for PR29078 'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32' llvm-svn: 280671
2016-09-06 02:11:17 +08:00
; X64-AVX-NEXT: retq
%clo = icmp slt <2 x i64> %a, <i64 -255, i64 -255>
%lo = select <2 x i1> %clo, <2 x i64> <i64 -255, i64 -255>, <2 x i64> %a
%chi = icmp sgt <2 x i64> %lo, <i64 255, i64 255>
%hi = select <2 x i1> %chi, <2 x i64> <i64 255, i64 255>, <2 x i64> %lo
%cvt = sitofp <2 x i64> %hi to <2 x double>
ret <2 x double> %cvt
}