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/ftrunc.ll

408 lines
13 KiB
LLVM
Raw Normal View History

[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=SSE2
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse4.1 | FileCheck %s --check-prefix=SSE41
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=AVX1
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define float @trunc_unsigned_f32(float %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_unsigned_f32:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttss2si %xmm0, %rax
; SSE2-NEXT: movl %eax, %eax
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2ss %rax, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_unsigned_f32:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundss $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_unsigned_f32:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundss $11, %xmm0, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptoui float %x to i32
%r = uitofp i32 %i to float
ret float %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define double @trunc_unsigned_f64(double %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_unsigned_f64:
; SSE2: # %bb.0:
; SSE2-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
; SSE2-NEXT: movapd %xmm0, %xmm2
; SSE2-NEXT: subsd %xmm1, %xmm2
; SSE2-NEXT: cvttsd2si %xmm2, %rax
; SSE2-NEXT: movabsq $-9223372036854775808, %rcx # imm = 0x8000000000000000
; SSE2-NEXT: xorq %rax, %rcx
; SSE2-NEXT: cvttsd2si %xmm0, %rax
; SSE2-NEXT: ucomisd %xmm1, %xmm0
; SSE2-NEXT: cmovaeq %rcx, %rax
; SSE2-NEXT: movq %rax, %xmm1
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],mem[0],xmm1[1],mem[1]
; SSE2-NEXT: subpd {{.*}}(%rip), %xmm1
[X86] Remove an fp->int->fp domain crossing in LowerUINT_TO_FP_i64. Summary: This unfortunately adds a move, but isn't that better than going to the int domain and back? Reviewers: RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52134 llvm-svn: 342327
2018-09-16 00:23:35 +08:00
; SSE2-NEXT: movapd %xmm1, %xmm0
; SSE2-NEXT: unpckhpd {{.*#+}} xmm0 = xmm0[1],xmm1[1]
[x86] scalarize extract element 0 of FP math This is another step towards ensuring that we produce the optimal code for reductions, but there are other potential benefits as seen in the tests diffs: 1. Memory loads may get scalarized resulting in more efficient code. 2. Memory stores may get scalarized resulting in more efficient code. 3. Complex ops like fdiv/sqrt get scalarized which may be faster instructions depending on uarch. 4. Even simple ops like addss/subss/mulss/roundss may result in faster operation/less frequency throttling when scalarized depending on uarch. The TODO comment suggests 1 or more follow-ups for opcodes that can currently result in regressions. Differential Revision: https://reviews.llvm.org/D58282 llvm-svn: 355130
2019-03-01 03:47:04 +08:00
; SSE2-NEXT: addsd %xmm1, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_unsigned_f64:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundsd $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_unsigned_f64:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundsd $11, %xmm0, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptoui double %x to i64
%r = uitofp i64 %i to double
ret double %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define <4 x float> @trunc_unsigned_v4f32(<4 x float> %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_unsigned_v4f32:
; SSE2: # %bb.0:
[VectorLegalizer] Enable TargetLowering::expandFP_TO_UINT support. Add vector support to TargetLowering::expandFP_TO_UINT. This exposes an issue in X86TargetLowering::LowerVSELECT which was assuming that the select mask was the same width as the LHS/RHS ops - as long as the result is a sign splat we can easily sext/trunk this. llvm-svn: 345473
2018-10-28 21:07:25 +08:00
; SSE2-NEXT: movaps {{.*#+}} xmm2 = [2.14748365E+9,2.14748365E+9,2.14748365E+9,2.14748365E+9]
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: movaps %xmm0, %xmm1
[VectorLegalizer] Enable TargetLowering::expandFP_TO_UINT support. Add vector support to TargetLowering::expandFP_TO_UINT. This exposes an issue in X86TargetLowering::LowerVSELECT which was assuming that the select mask was the same width as the LHS/RHS ops - as long as the result is a sign splat we can easily sext/trunk this. llvm-svn: 345473
2018-10-28 21:07:25 +08:00
; SSE2-NEXT: cmpltps %xmm2, %xmm1
; SSE2-NEXT: cvttps2dq %xmm0, %xmm3
; SSE2-NEXT: subps %xmm2, %xmm0
; SSE2-NEXT: cvttps2dq %xmm0, %xmm0
; SSE2-NEXT: xorps {{.*}}(%rip), %xmm0
; SSE2-NEXT: andps %xmm1, %xmm3
; SSE2-NEXT: andnps %xmm0, %xmm1
; SSE2-NEXT: orps %xmm3, %xmm1
; SSE2-NEXT: movaps {{.*#+}} xmm0 = [65535,65535,65535,65535]
; SSE2-NEXT: andps %xmm1, %xmm0
; SSE2-NEXT: orps {{.*}}(%rip), %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: psrld $16, %xmm1
; SSE2-NEXT: por {{.*}}(%rip), %xmm1
; SSE2-NEXT: addps {{.*}}(%rip), %xmm1
; SSE2-NEXT: addps %xmm0, %xmm1
; SSE2-NEXT: movaps %xmm1, %xmm0
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_unsigned_v4f32:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundps $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_unsigned_v4f32:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundps $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptoui <4 x float> %x to <4 x i32>
%r = uitofp <4 x i32> %i to <4 x float>
ret <4 x float> %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define <2 x double> @trunc_unsigned_v2f64(<2 x double> %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_unsigned_v2f64:
; SSE2: # %bb.0:
; SSE2-NEXT: movsd {{.*#+}} xmm2 = mem[0],zero
[X86] Prefer unpckhpd over movhlps in isel for fake unary cases In r337348, I changed lowering to prefer X86ISD::UNPCKL/UNPCKH opcodes over MOVLHPS/MOVHLPS for v2f64 {0,0} and {1,1} shuffles when we have SSE2. This enabled the removal of a bunch of weirdly bitcasted isel patterns in r337349. To avoid changing the tests I placed a gross hack in isel to still emit movhlps instructions for fake unary unpckh nodes. A similar hack was not needed for unpckl and movlhps because we do execution domain switching for those. But unpckh and movhlps have swapped operand order. This patch removes the hack. This is a code size increase since unpckhpd requires a 0x66 prefix and movhlps does not. But if that's a big concern we should be using movhlps for all unpckhpd opcodes and let commuteInstruction turnit into unpckhpd when its an advantage. Differential Revision: https://reviews.llvm.org/D49499 llvm-svn: 341973
2018-09-12 01:57:27 +08:00
; SSE2-NEXT: movapd %xmm0, %xmm1
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: subsd %xmm2, %xmm1
; SSE2-NEXT: cvttsd2si %xmm1, %rax
[TargetLowering] Improve vXi64 UINT_TO_FP vXf64 support (P38226) As suggested on D52965, this patch moves the i64 to f64 UINT_TO_FP expansion code from LegalizeDAG into TargetLowering and makes it available to LegalizeVectorOps as well. Not only does this help perform X86 lowering as a true vectorization instead of (partially vectorized) scalar conversions, it avoids the HADDPD op from the scalar code which can be slow on most targets. The AVX512F does have the vcvtusi2sdq scalar operation but we don't unroll to use it as it seems to only help for the v2f64 case - otherwise the unrolling cost will certainly be too high. My feeling is that we should leave it to the vectorizers - and if it generates the vector UINT_TO_FP we should use it. Differential Revision: https://reviews.llvm.org/D53649 llvm-svn: 345256
2018-10-25 19:15:57 +08:00
; SSE2-NEXT: movabsq $-9223372036854775808, %rcx # imm = 0x8000000000000000
; SSE2-NEXT: xorq %rcx, %rax
; SSE2-NEXT: cvttsd2si %xmm0, %rdx
; SSE2-NEXT: ucomisd %xmm2, %xmm0
; SSE2-NEXT: cmovaeq %rax, %rdx
; SSE2-NEXT: movq %rdx, %xmm1
; SSE2-NEXT: unpckhpd {{.*#+}} xmm0 = xmm0[1,1]
; SSE2-NEXT: movapd %xmm0, %xmm3
; SSE2-NEXT: subsd %xmm2, %xmm3
; SSE2-NEXT: cvttsd2si %xmm3, %rax
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: xorq %rcx, %rax
; SSE2-NEXT: cvttsd2si %xmm0, %rcx
; SSE2-NEXT: ucomisd %xmm2, %xmm0
; SSE2-NEXT: cmovaeq %rax, %rcx
[TargetLowering] Improve vXi64 UINT_TO_FP vXf64 support (P38226) As suggested on D52965, this patch moves the i64 to f64 UINT_TO_FP expansion code from LegalizeDAG into TargetLowering and makes it available to LegalizeVectorOps as well. Not only does this help perform X86 lowering as a true vectorization instead of (partially vectorized) scalar conversions, it avoids the HADDPD op from the scalar code which can be slow on most targets. The AVX512F does have the vcvtusi2sdq scalar operation but we don't unroll to use it as it seems to only help for the v2f64 case - otherwise the unrolling cost will certainly be too high. My feeling is that we should leave it to the vectorizers - and if it generates the vector UINT_TO_FP we should use it. Differential Revision: https://reviews.llvm.org/D53649 llvm-svn: 345256
2018-10-25 19:15:57 +08:00
; SSE2-NEXT: movq %rcx, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSE2-NEXT: movdqa {{.*#+}} xmm0 = [4294967295,4294967295]
; SSE2-NEXT: pand %xmm1, %xmm0
; SSE2-NEXT: por {{.*}}(%rip), %xmm0
; SSE2-NEXT: psrlq $32, %xmm1
; SSE2-NEXT: por {{.*}}(%rip), %xmm1
; SSE2-NEXT: subpd {{.*}}(%rip), %xmm1
; SSE2-NEXT: addpd %xmm0, %xmm1
[X86] Remove an fp->int->fp domain crossing in LowerUINT_TO_FP_i64. Summary: This unfortunately adds a move, but isn't that better than going to the int domain and back? Reviewers: RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52134 llvm-svn: 342327
2018-09-16 00:23:35 +08:00
; SSE2-NEXT: movapd %xmm1, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_unsigned_v2f64:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundpd $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_unsigned_v2f64:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundpd $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptoui <2 x double> %x to <2 x i64>
%r = uitofp <2 x i64> %i to <2 x double>
ret <2 x double> %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define <4 x double> @trunc_unsigned_v4f64(<4 x double> %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_unsigned_v4f64:
; SSE2: # %bb.0:
[TargetLowering] Improve vXi64 UINT_TO_FP vXf64 support (P38226) As suggested on D52965, this patch moves the i64 to f64 UINT_TO_FP expansion code from LegalizeDAG into TargetLowering and makes it available to LegalizeVectorOps as well. Not only does this help perform X86 lowering as a true vectorization instead of (partially vectorized) scalar conversions, it avoids the HADDPD op from the scalar code which can be slow on most targets. The AVX512F does have the vcvtusi2sdq scalar operation but we don't unroll to use it as it seems to only help for the v2f64 case - otherwise the unrolling cost will certainly be too high. My feeling is that we should leave it to the vectorizers - and if it generates the vector UINT_TO_FP we should use it. Differential Revision: https://reviews.llvm.org/D53649 llvm-svn: 345256
2018-10-25 19:15:57 +08:00
; SSE2-NEXT: movapd %xmm1, %xmm2
; SSE2-NEXT: movsd {{.*#+}} xmm3 = mem[0],zero
; SSE2-NEXT: subsd %xmm3, %xmm1
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: cvttsd2si %xmm1, %rcx
[TargetLowering] Improve vXi64 UINT_TO_FP vXf64 support (P38226) As suggested on D52965, this patch moves the i64 to f64 UINT_TO_FP expansion code from LegalizeDAG into TargetLowering and makes it available to LegalizeVectorOps as well. Not only does this help perform X86 lowering as a true vectorization instead of (partially vectorized) scalar conversions, it avoids the HADDPD op from the scalar code which can be slow on most targets. The AVX512F does have the vcvtusi2sdq scalar operation but we don't unroll to use it as it seems to only help for the v2f64 case - otherwise the unrolling cost will certainly be too high. My feeling is that we should leave it to the vectorizers - and if it generates the vector UINT_TO_FP we should use it. Differential Revision: https://reviews.llvm.org/D53649 llvm-svn: 345256
2018-10-25 19:15:57 +08:00
; SSE2-NEXT: movabsq $-9223372036854775808, %rax # imm = 0x8000000000000000
; SSE2-NEXT: xorq %rax, %rcx
; SSE2-NEXT: cvttsd2si %xmm2, %rdx
; SSE2-NEXT: ucomisd %xmm3, %xmm2
; SSE2-NEXT: cmovaeq %rcx, %rdx
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: movq %rdx, %xmm1
[TargetLowering] Improve vXi64 UINT_TO_FP vXf64 support (P38226) As suggested on D52965, this patch moves the i64 to f64 UINT_TO_FP expansion code from LegalizeDAG into TargetLowering and makes it available to LegalizeVectorOps as well. Not only does this help perform X86 lowering as a true vectorization instead of (partially vectorized) scalar conversions, it avoids the HADDPD op from the scalar code which can be slow on most targets. The AVX512F does have the vcvtusi2sdq scalar operation but we don't unroll to use it as it seems to only help for the v2f64 case - otherwise the unrolling cost will certainly be too high. My feeling is that we should leave it to the vectorizers - and if it generates the vector UINT_TO_FP we should use it. Differential Revision: https://reviews.llvm.org/D53649 llvm-svn: 345256
2018-10-25 19:15:57 +08:00
; SSE2-NEXT: unpckhpd {{.*#+}} xmm2 = xmm2[1,1]
; SSE2-NEXT: movapd %xmm2, %xmm4
; SSE2-NEXT: subsd %xmm3, %xmm4
; SSE2-NEXT: cvttsd2si %xmm4, %rcx
; SSE2-NEXT: xorq %rax, %rcx
; SSE2-NEXT: cvttsd2si %xmm2, %rdx
; SSE2-NEXT: ucomisd %xmm3, %xmm2
; SSE2-NEXT: cmovaeq %rcx, %rdx
; SSE2-NEXT: movq %rdx, %xmm2
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSE2-NEXT: movapd %xmm0, %xmm2
; SSE2-NEXT: subsd %xmm3, %xmm2
; SSE2-NEXT: cvttsd2si %xmm2, %rcx
; SSE2-NEXT: xorq %rax, %rcx
; SSE2-NEXT: cvttsd2si %xmm0, %rdx
; SSE2-NEXT: ucomisd %xmm3, %xmm0
; SSE2-NEXT: cmovaeq %rcx, %rdx
; SSE2-NEXT: movq %rdx, %xmm2
; SSE2-NEXT: unpckhpd {{.*#+}} xmm0 = xmm0[1,1]
; SSE2-NEXT: movapd %xmm0, %xmm4
; SSE2-NEXT: subsd %xmm3, %xmm4
; SSE2-NEXT: cvttsd2si %xmm4, %rcx
; SSE2-NEXT: xorq %rax, %rcx
; SSE2-NEXT: cvttsd2si %xmm0, %rax
; SSE2-NEXT: ucomisd %xmm3, %xmm0
; SSE2-NEXT: cmovaeq %rcx, %rax
; SSE2-NEXT: movq %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm0[0]
; SSE2-NEXT: movdqa {{.*#+}} xmm0 = [4294967295,4294967295]
; SSE2-NEXT: movdqa %xmm2, %xmm3
; SSE2-NEXT: pand %xmm0, %xmm3
; SSE2-NEXT: movdqa {{.*#+}} xmm4 = [4841369599423283200,4841369599423283200]
; SSE2-NEXT: por %xmm4, %xmm3
; SSE2-NEXT: psrlq $32, %xmm2
; SSE2-NEXT: movdqa {{.*#+}} xmm5 = [4985484787499139072,4985484787499139072]
; SSE2-NEXT: por %xmm5, %xmm2
; SSE2-NEXT: movapd {{.*#+}} xmm6 = [1.9342813118337666E+25,1.9342813118337666E+25]
; SSE2-NEXT: subpd %xmm6, %xmm2
; SSE2-NEXT: addpd %xmm3, %xmm2
; SSE2-NEXT: pand %xmm1, %xmm0
; SSE2-NEXT: por %xmm4, %xmm0
; SSE2-NEXT: psrlq $32, %xmm1
; SSE2-NEXT: por %xmm5, %xmm1
; SSE2-NEXT: subpd %xmm6, %xmm1
; SSE2-NEXT: addpd %xmm0, %xmm1
; SSE2-NEXT: movapd %xmm2, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_unsigned_v4f64:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundpd $11, %xmm0, %xmm0
; SSE41-NEXT: roundpd $11, %xmm1, %xmm1
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_unsigned_v4f64:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundpd $11, %ymm0, %ymm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptoui <4 x double> %x to <4 x i64>
%r = uitofp <4 x i64> %i to <4 x double>
ret <4 x double> %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define float @trunc_signed_f32(float %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_signed_f32:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttss2si %xmm0, %eax
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2ss %eax, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_signed_f32:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundss $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_signed_f32:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundss $11, %xmm0, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptosi float %x to i32
%r = sitofp i32 %i to float
ret float %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define double @trunc_signed_f64(double %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_signed_f64:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttsd2si %xmm0, %rax
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2sd %rax, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_signed_f64:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundsd $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_signed_f64:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundsd $11, %xmm0, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptosi double %x to i64
%r = sitofp i64 %i to double
ret double %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define <4 x float> @trunc_signed_v4f32(<4 x float> %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_signed_v4f32:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttps2dq %xmm0, %xmm0
; SSE2-NEXT: cvtdq2ps %xmm0, %xmm0
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_signed_v4f32:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundps $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_signed_v4f32:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundps $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptosi <4 x float> %x to <4 x i32>
%r = sitofp <4 x i32> %i to <4 x float>
ret <4 x float> %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define <2 x double> @trunc_signed_v2f64(<2 x double> %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_signed_v2f64:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttsd2si %xmm0, %rax
; SSE2-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; SSE2-NEXT: cvttsd2si %xmm0, %rcx
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2sd %rax, %xmm0
; SSE2-NEXT: cvtsi2sd %rcx, %xmm1
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: movlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_signed_v2f64:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundpd $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_signed_v2f64:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundpd $11, %xmm0, %xmm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptosi <2 x double> %x to <2 x i64>
%r = sitofp <2 x i64> %i to <2 x double>
ret <2 x double> %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
define <4 x double> @trunc_signed_v4f64(<4 x double> %x) #0 {
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-LABEL: trunc_signed_v4f64:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttsd2si %xmm1, %rax
; SSE2-NEXT: movhlps {{.*#+}} xmm1 = xmm1[1,1]
; SSE2-NEXT: cvttsd2si %xmm1, %rcx
; SSE2-NEXT: cvttsd2si %xmm0, %rdx
; SSE2-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; SSE2-NEXT: cvttsd2si %xmm0, %rsi
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2sd %rdx, %xmm0
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: xorps %xmm1, %xmm1
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2sd %rsi, %xmm1
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: movlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: xorps %xmm1, %xmm1
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2sd %rax, %xmm1
; SSE2-NEXT: cvtsi2sd %rcx, %xmm2
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: movlhps {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSE2-NEXT: retq
;
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-LABEL: trunc_signed_v4f64:
; SSE41: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; SSE41-NEXT: roundpd $11, %xmm0, %xmm0
; SSE41-NEXT: roundpd $11, %xmm1, %xmm1
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_signed_v4f64:
; AVX1: # %bb.0:
[DAGCombine] (float)((int) f) --> ftrunc (PR36617) This was originally committed at rL328921 and reverted at rL329920 to investigate failures in Chrome. This time I've added to the ReleaseNotes to warn users of the potential of exposing UB and let me repeat that here for more exposure: Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on undefined behavior. Code sanitizers can be used to detect affected patterns such as this: int main() { float x = 4294967296.0f; x = (float)((int)x); printf("junk in the ftrunc: %f\n", x); return 0; } $ clang -O1 ftrunc.c -fsanitize=undefined ; ./a.out ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int' junk in the ftrunc: 0.000000 Original commit message: fptosi / fptoui round towards zero, and that's the same behavior as ISD::FTRUNC, so replace a pair of casts with the equivalent node. We don't have to account for special cases (NaN, INF) because out-of-range casts are undefined. Differential Revision: https://reviews.llvm.org/D44909 llvm-svn: 330437
2018-04-20 23:07:55 +08:00
; AVX1-NEXT: vroundpd $11, %ymm0, %ymm0
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
; AVX1-NEXT: retq
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
%i = fptosi <4 x double> %x to <4 x i64>
%r = sitofp <4 x i64> %i to <4 x double>
ret <4 x double> %r
[x86] add tests for ftrunc; NFC llvm-svn: 328592
2018-03-27 07:18:32 +08:00
}
[X86] Remove an fp->int->fp domain crossing in LowerUINT_TO_FP_i64. Summary: This unfortunately adds a move, but isn't that better than going to the int domain and back? Reviewers: RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52134 llvm-svn: 342327
2018-09-16 00:23:35 +08:00
; The fold may be guarded to allow existing code to continue
[DAGCombiner] rename function attribute for disabling ftrunc transform This is the matching name change for the Clang patch at: D46236 rL331209 Differential Revision: https://reviews.llvm.org/D46237 llvm-svn: 331210
2018-05-01 02:20:33 +08:00
; working based on its assumptions of float->int overflow.
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
define float @trunc_unsigned_f32_disable_via_attr(float %x) #1 {
; SSE2-LABEL: trunc_unsigned_f32_disable_via_attr:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttss2si %xmm0, %rax
; SSE2-NEXT: movl %eax, %eax
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2ss %rax, %xmm0
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
; SSE2-NEXT: retq
;
; SSE41-LABEL: trunc_unsigned_f32_disable_via_attr:
; SSE41: # %bb.0:
[DAGCombiner] limit ftrunc optimizations with function attribute As noted, the attribute name is subject to change once we have the clang side implemented, but it's clear that we need some kind of attribute-based predication here based on the discussion for: rL330437 llvm-svn: 330951
2018-04-27 00:04:44 +08:00
; SSE41-NEXT: cvttss2si %xmm0, %rax
; SSE41-NEXT: movl %eax, %eax
; SSE41-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE41-NEXT: cvtsi2ss %rax, %xmm0
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_unsigned_f32_disable_via_attr:
; AVX1: # %bb.0:
[DAGCombiner] limit ftrunc optimizations with function attribute As noted, the attribute name is subject to change once we have the clang side implemented, but it's clear that we need some kind of attribute-based predication here based on the discussion for: rL330437 llvm-svn: 330951
2018-04-27 00:04:44 +08:00
; AVX1-NEXT: vcvttss2si %xmm0, %rax
; AVX1-NEXT: movl %eax, %eax
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; AVX1-NEXT: vcvtsi2ss %rax, %xmm1, %xmm0
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
; AVX1-NEXT: retq
%i = fptoui float %x to i32
%r = uitofp i32 %i to float
ret float %r
}
define double @trunc_signed_f64_disable_via_attr(double %x) #1 {
; SSE2-LABEL: trunc_signed_f64_disable_via_attr:
; SSE2: # %bb.0:
; SSE2-NEXT: cvttsd2si %xmm0, %rax
; SSE2-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE2-NEXT: cvtsi2sd %rax, %xmm0
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
; SSE2-NEXT: retq
;
; SSE41-LABEL: trunc_signed_f64_disable_via_attr:
; SSE41: # %bb.0:
[DAGCombiner] limit ftrunc optimizations with function attribute As noted, the attribute name is subject to change once we have the clang side implemented, but it's clear that we need some kind of attribute-based predication here based on the discussion for: rL330437 llvm-svn: 330951
2018-04-27 00:04:44 +08:00
; SSE41-NEXT: cvttsd2si %xmm0, %rax
; SSE41-NEXT: xorps %xmm0, %xmm0
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; SSE41-NEXT: cvtsi2sd %rax, %xmm0
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
; SSE41-NEXT: retq
;
; AVX1-LABEL: trunc_signed_f64_disable_via_attr:
; AVX1: # %bb.0:
[DAGCombiner] limit ftrunc optimizations with function attribute As noted, the attribute name is subject to change once we have the clang side implemented, but it's clear that we need some kind of attribute-based predication here based on the discussion for: rL330437 llvm-svn: 330951
2018-04-27 00:04:44 +08:00
; AVX1-NEXT: vcvttsd2si %xmm0, %rax
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; AVX1-NEXT: vcvtsi2sd %rax, %xmm1, %xmm0
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00
; AVX1-NEXT: retq
%i = fptosi double %x to i64
%r = sitofp i64 %i to double
ret double %r
}
[DAGCombiner] restrict (float)((int) f) --> ftrunc with no-signed-zeros As noted in the D44909 review, the transform from (fptosi+sitofp) to ftrunc can produce -0.0 where the original code does not: #include <stdio.h> int main(int argc) { float x; x = -0.8 * argc; printf("%f\n", (float)((int)x)); return 0; } $ clang -O0 -mavx fp.c ; ./a.out 0.000000 $ clang -O1 -mavx fp.c ; ./a.out -0.000000 Ideally, we'd use IR/node flags to predicate the transform, but the IR parser doesn't currently allow fast-math-flags on the cast instructions. So for now, just use the function attribute that corresponds to clang's "-fno-signed-zeros" option. Differential Revision: https://reviews.llvm.org/D48085 llvm-svn: 335761
2018-06-28 02:16:40 +08:00
attributes #0 = { nounwind "no-signed-zeros-fp-math"="true" }
attributes #1 = { nounwind "no-signed-zeros-fp-math"="true" "strict-float-cast-overflow"="false" }
[x86] add tests to show potential opt-out of ftrunc optimization; NFC This is another preliminary step for disabling this transform as discussed in the post-commit thread for: rL330437 I'm using one of the names suggested there for the attribute, but we can fix that up as needed once the clang side of this is sorted out. llvm-svn: 330950
2018-04-26 23:36:15 +08:00