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

418 lines
14 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
; SSE2-NEXT: cvtsi2ssq %rax, %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_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
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: addpd %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_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:
; SSE2-NEXT: movaps %xmm0, %xmm1
; SSE2-NEXT: shufps {{.*#+}} xmm1 = xmm1[3,1],xmm0[2,3]
; SSE2-NEXT: cvttss2si %xmm1, %rax
; SSE2-NEXT: movd %eax, %xmm1
; SSE2-NEXT: movaps %xmm0, %xmm2
[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: unpckhpd {{.*#+}} xmm2 = xmm2[1],xmm0[1]
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: cvttss2si %xmm2, %rax
; SSE2-NEXT: movd %eax, %xmm2
; SSE2-NEXT: punpckldq {{.*#+}} xmm2 = xmm2[0],xmm1[0],xmm2[1],xmm1[1]
; SSE2-NEXT: cvttss2si %xmm0, %rax
; SSE2-NEXT: movd %eax, %xmm1
; SSE2-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,2,3]
; SSE2-NEXT: cvttss2si %xmm0, %rax
; SSE2-NEXT: movd %eax, %xmm0
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSE2-NEXT: movdqa {{.*#+}} xmm0 = [65535,65535,65535,65535]
; SSE2-NEXT: pand %xmm1, %xmm0
; SSE2-NEXT: por {{.*}}(%rip), %xmm0
; 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:
[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
; SSE2-NEXT: unpckhpd {{.*#+}} xmm1 = xmm1[1],xmm0[1]
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; 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 %xmm1, %xmm3
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: subsd %xmm2, %xmm3
; SSE2-NEXT: cvttsd2si %xmm3, %rax
; SSE2-NEXT: movabsq $-9223372036854775808, %rcx # imm = 0x8000000000000000
; SSE2-NEXT: xorq %rcx, %rax
; SSE2-NEXT: cvttsd2si %xmm1, %rdx
; SSE2-NEXT: ucomisd %xmm2, %xmm1
; SSE2-NEXT: cmovaeq %rax, %rdx
[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
; SSE2-NEXT: xorq %rcx, %rax
; SSE2-NEXT: cvttsd2si %xmm0, %rcx
; SSE2-NEXT: ucomisd %xmm2, %xmm0
; SSE2-NEXT: cmovaeq %rax, %rcx
; SSE2-NEXT: movq %rcx, %xmm1
; SSE2-NEXT: movdqa {{.*#+}} xmm2 = [1127219200,1160773632,0,0]
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; SSE2-NEXT: movapd {{.*#+}} xmm3 = [4.503600e+15,1.934281e+25]
; SSE2-NEXT: subpd %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: addpd %xmm1, %xmm0
; SSE2-NEXT: movq %rdx, %xmm1
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; SSE2-NEXT: subpd %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm1[2,3,0,1]
; SSE2-NEXT: addpd %xmm1, %xmm2
; SSE2-NEXT: unpcklpd {{.*#+}} xmm0 = xmm0[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_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:
[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 %xmm1, %xmm3
; SSE2-NEXT: unpckhpd {{.*#+}} xmm3 = xmm3[1],xmm1[1]
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; 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 %xmm3, %xmm4
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: subsd %xmm2, %xmm4
; SSE2-NEXT: cvttsd2si %xmm4, %rcx
; SSE2-NEXT: movabsq $-9223372036854775808, %rdx # imm = 0x8000000000000000
; SSE2-NEXT: xorq %rdx, %rcx
; SSE2-NEXT: cvttsd2si %xmm3, %rax
; SSE2-NEXT: ucomisd %xmm2, %xmm3
; SSE2-NEXT: cmovaeq %rcx, %rax
[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 %xmm1, %xmm3
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: subsd %xmm2, %xmm3
; SSE2-NEXT: cvttsd2si %xmm3, %rsi
; SSE2-NEXT: xorq %rdx, %rsi
; SSE2-NEXT: cvttsd2si %xmm1, %rcx
; SSE2-NEXT: ucomisd %xmm2, %xmm1
; SSE2-NEXT: cmovaeq %rsi, %rcx
[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
; SSE2-NEXT: unpckhpd {{.*#+}} xmm1 = xmm1[1],xmm0[1]
; SSE2-NEXT: movapd %xmm1, %xmm3
[x86] add RUN for target before roundss; NFC llvm-svn: 328601
2018-03-27 08:32:19 +08:00
; SSE2-NEXT: subsd %xmm2, %xmm3
; SSE2-NEXT: cvttsd2si %xmm3, %rsi
; SSE2-NEXT: xorq %rdx, %rsi
; SSE2-NEXT: cvttsd2si %xmm1, %rdi
; SSE2-NEXT: ucomisd %xmm2, %xmm1
; SSE2-NEXT: cmovaeq %rsi, %rdi
[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, %rsi
; SSE2-NEXT: xorq %rdx, %rsi
; SSE2-NEXT: cvttsd2si %xmm0, %rdx
; SSE2-NEXT: ucomisd %xmm2, %xmm0
; SSE2-NEXT: cmovaeq %rsi, %rdx
; SSE2-NEXT: movq %rdx, %xmm1
; SSE2-NEXT: movdqa {{.*#+}} xmm2 = [1127219200,1160773632,0,0]
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; SSE2-NEXT: movapd {{.*#+}} xmm3 = [4.503600e+15,1.934281e+25]
; SSE2-NEXT: subpd %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm1[2,3,0,1]
; SSE2-NEXT: addpd %xmm1, %xmm0
; SSE2-NEXT: movq %rdi, %xmm1
; SSE2-NEXT: punpckldq {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; SSE2-NEXT: subpd %xmm3, %xmm1
; SSE2-NEXT: pshufd {{.*#+}} xmm4 = xmm1[2,3,0,1]
; SSE2-NEXT: addpd %xmm1, %xmm4
; SSE2-NEXT: unpcklpd {{.*#+}} xmm0 = xmm0[0],xmm4[0]
; SSE2-NEXT: movq %rcx, %xmm4
; SSE2-NEXT: punpckldq {{.*#+}} xmm4 = xmm4[0],xmm2[0],xmm4[1],xmm2[1]
; SSE2-NEXT: subpd %xmm3, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm4[2,3,0,1]
; SSE2-NEXT: addpd %xmm4, %xmm1
; SSE2-NEXT: movq %rax, %xmm4
; SSE2-NEXT: punpckldq {{.*#+}} xmm4 = xmm4[0],xmm2[0],xmm4[1],xmm2[1]
; SSE2-NEXT: subpd %xmm3, %xmm4
; SSE2-NEXT: pshufd {{.*#+}} xmm2 = xmm4[2,3,0,1]
; SSE2-NEXT: addpd %xmm4, %xmm2
; SSE2-NEXT: unpcklpd {{.*#+}} 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_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
; SSE2-NEXT: cvtsi2ssl %eax, %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_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
; SSE2-NEXT: cvtsi2sdq %rax, %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_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
; SSE2-NEXT: cvtsi2sdq %rax, %xmm0
; SSE2-NEXT: cvtsi2sdq %rcx, %xmm1
; 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
; SSE2-NEXT: cvtsi2sdq %rdx, %xmm0
; SSE2-NEXT: xorps %xmm1, %xmm1
; SSE2-NEXT: cvtsi2sdq %rsi, %xmm1
; SSE2-NEXT: movlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: xorps %xmm1, %xmm1
; SSE2-NEXT: cvtsi2sdq %rax, %xmm1
; SSE2-NEXT: cvtsi2sdq %rcx, %xmm2
; 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
}
[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
; The fold may be guarded to allow existing code to continue
; 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
; SSE2-NEXT: cvtsi2ssq %rax, %xmm0
; 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
; SSE41-NEXT: cvtsi2ssq %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
; AVX1-NEXT: vcvtsi2ssq %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
; SSE2-NEXT: cvtsi2sdq %rax, %xmm0
; 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
; SSE41-NEXT: cvtsi2sdq %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
; AVX1-NEXT: vcvtsi2sdq %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