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

46 lines
1.3 KiB
LLVM
Raw Normal View History

[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc -mcpu=pwr8 -mtriple=powerpc64le-unknown-unknown -verify-machineinstrs < %s | FileCheck %s
[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> @truncf32(<4 x float> %a) #0 {
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-LABEL: truncf32:
; CHECK: # %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
; CHECK-NEXT: xvrspiz 34, 34
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-NEXT: blr
%t0 = fptosi <4 x float> %a to <4 x i32>
%t1 = sitofp <4 x i32> %t0 to <4 x float>
ret <4 x float> %t1
}
[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> @truncf64(<2 x double> %a) #0 {
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-LABEL: truncf64:
; CHECK: # %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
; CHECK-NEXT: xvrdpiz 34, 34
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-NEXT: blr
%t0 = fptosi <2 x double> %a to <2 x i64>
%t1 = sitofp <2 x i64> %t0 to <2 x double>
ret <2 x double> %t1
}
[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> @truncf32u(<4 x float> %a) #0 {
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-LABEL: truncf32u:
; CHECK: # %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
; CHECK-NEXT: xvrspiz 34, 34
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-NEXT: blr
%t0 = fptoui <4 x float> %a to <4 x i32>
%t1 = uitofp <4 x i32> %t0 to <4 x float>
ret <4 x float> %t1
}
[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> @truncf64u(<2 x double> %a) #0 {
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-LABEL: truncf64u:
; CHECK: # %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
; CHECK-NEXT: xvrdpiz 34, 34
[PowerPC] add ftrunc vector tests; NFC Baseline tests for vectors as suggested in D44909. llvm-svn: 328682
2018-03-28 08:49:12 +08:00
; CHECK-NEXT: blr
%t0 = fptoui <2 x double> %a to <2 x i64>
%t1 = uitofp <2 x i64> %t0 to <2 x double>
ret <2 x double> %t1
}
[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 = { "no-signed-zeros-fp-math"="true" }