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/AArch64/fp-const-fold.ll

77 lines
2.0 KiB
LLVM
Raw Normal View History

[AArch64] add tests for fdiv/frem constant folding (PR41668); NFC llvm-svn: 359561
2019-04-30 21:43:17 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=aarch64-- | FileCheck %s
; https://bugs.llvm.org/show_bug.cgi?id=41668
define double @constant_fold_fdiv_by_zero(double* %p) {
; CHECK-LABEL: constant_fold_fdiv_by_zero:
; CHECK: // %bb.0:
[SelectionDAG] remove div-by-zero constant folding restriction We don't have this restriction in IR, so it should not be here either simply out of consistency. Code that wants to handle FP exceptions is expected to use the 'strict' variants of these nodes. We don't get the frem case because frem by 0.0 produces NaN (invalid), and that's the remaining check here (so the removed check for frem was dead code AFAIK). This is the only place in SDAG that uses "HasFPExceptions", so I think we should remove that entirely as a follow-up patch. llvm-svn: 359566
2019-04-30 22:37:15 +08:00
; CHECK-NEXT: mov x8, #9218868437227405312
; CHECK-NEXT: fmov d0, x8
[AArch64] add tests for fdiv/frem constant folding (PR41668); NFC llvm-svn: 359561
2019-04-30 21:43:17 +08:00
; CHECK-NEXT: ret
%r = fdiv double 4.940660e-324, 0.0
ret double %r
}
[AArch64] add more tests for constant folding failures; NFC llvm-svn: 359592
2019-05-01 02:15:18 +08:00
; frem by 0.0 --> NaN
[AArch64] add tests for fdiv/frem constant folding (PR41668); NFC llvm-svn: 359561
2019-04-30 21:43:17 +08:00
define double @constant_fold_frem_by_zero(double* %p) {
; CHECK-LABEL: constant_fold_frem_by_zero:
; CHECK: // %bb.0:
[SelectionDAG] remove constant folding limitations based on FP exceptions We don't have FP exception limits in the IR constant folder for the binops (apart from strict ops), so it does not make sense to have them here in the DAG either. Nothing else in the backend tries to preserve exceptions (again outside of strict ops), so I don't see how this could have ever worked for real code that cares about FP exceptions. There are still cases (examples: unary opcodes in SDAG, FMA in IR) where we are trying (at least partially) to preserve exceptions without even asking if the target supports FP exceptions. Those should be corrected in subsequent patches. Real support for FP exceptions requires several changes to handle the constrained/strict FP ops. Differential Revision: https://reviews.llvm.org/D61331 llvm-svn: 359791
2019-05-02 22:47:59 +08:00
; CHECK-NEXT: mov x8, #9221120237041090560
[AArch64] add tests for fdiv/frem constant folding (PR41668); NFC llvm-svn: 359561
2019-04-30 21:43:17 +08:00
; CHECK-NEXT: fmov d0, x8
[SelectionDAG] remove constant folding limitations based on FP exceptions We don't have FP exception limits in the IR constant folder for the binops (apart from strict ops), so it does not make sense to have them here in the DAG either. Nothing else in the backend tries to preserve exceptions (again outside of strict ops), so I don't see how this could have ever worked for real code that cares about FP exceptions. There are still cases (examples: unary opcodes in SDAG, FMA in IR) where we are trying (at least partially) to preserve exceptions without even asking if the target supports FP exceptions. Those should be corrected in subsequent patches. Real support for FP exceptions requires several changes to handle the constrained/strict FP ops. Differential Revision: https://reviews.llvm.org/D61331 llvm-svn: 359791
2019-05-02 22:47:59 +08:00
; CHECK-NEXT: ret
[AArch64] add tests for fdiv/frem constant folding (PR41668); NFC llvm-svn: 359561
2019-04-30 21:43:17 +08:00
%r = frem double 4.940660e-324, 0.0
ret double %r
}
[AArch64] add more tests for constant folding failures; NFC llvm-svn: 359592
2019-05-01 02:15:18 +08:00
; Inf * 0.0 --> NaN
define double @constant_fold_fmul_nan(double* %p) {
; CHECK-LABEL: constant_fold_fmul_nan:
; CHECK: // %bb.0:
[SelectionDAG] remove constant folding limitations based on FP exceptions We don't have FP exception limits in the IR constant folder for the binops (apart from strict ops), so it does not make sense to have them here in the DAG either. Nothing else in the backend tries to preserve exceptions (again outside of strict ops), so I don't see how this could have ever worked for real code that cares about FP exceptions. There are still cases (examples: unary opcodes in SDAG, FMA in IR) where we are trying (at least partially) to preserve exceptions without even asking if the target supports FP exceptions. Those should be corrected in subsequent patches. Real support for FP exceptions requires several changes to handle the constrained/strict FP ops. Differential Revision: https://reviews.llvm.org/D61331 llvm-svn: 359791
2019-05-02 22:47:59 +08:00
; CHECK-NEXT: mov x8, #9221120237041090560
; CHECK-NEXT: fmov d0, x8
[AArch64] add more tests for constant folding failures; NFC llvm-svn: 359592
2019-05-01 02:15:18 +08:00
; CHECK-NEXT: ret
%r = fmul double 0x7ff0000000000000, 0.0
ret double %r
}
; Inf + -Inf --> NaN
define double @constant_fold_fadd_nan(double* %p) {
; CHECK-LABEL: constant_fold_fadd_nan:
; CHECK: // %bb.0:
[SelectionDAG] remove constant folding limitations based on FP exceptions We don't have FP exception limits in the IR constant folder for the binops (apart from strict ops), so it does not make sense to have them here in the DAG either. Nothing else in the backend tries to preserve exceptions (again outside of strict ops), so I don't see how this could have ever worked for real code that cares about FP exceptions. There are still cases (examples: unary opcodes in SDAG, FMA in IR) where we are trying (at least partially) to preserve exceptions without even asking if the target supports FP exceptions. Those should be corrected in subsequent patches. Real support for FP exceptions requires several changes to handle the constrained/strict FP ops. Differential Revision: https://reviews.llvm.org/D61331 llvm-svn: 359791
2019-05-02 22:47:59 +08:00
; CHECK-NEXT: mov x8, #9221120237041090560
[AArch64] add more tests for constant folding failures; NFC llvm-svn: 359592
2019-05-01 02:15:18 +08:00
; CHECK-NEXT: fmov d0, x8
; CHECK-NEXT: ret
%r = fadd double 0x7ff0000000000000, 0xfff0000000000000
ret double %r
}
; Inf - Inf --> NaN
define double @constant_fold_fsub_nan(double* %p) {
; CHECK-LABEL: constant_fold_fsub_nan:
; CHECK: // %bb.0:
[SelectionDAG] remove constant folding limitations based on FP exceptions We don't have FP exception limits in the IR constant folder for the binops (apart from strict ops), so it does not make sense to have them here in the DAG either. Nothing else in the backend tries to preserve exceptions (again outside of strict ops), so I don't see how this could have ever worked for real code that cares about FP exceptions. There are still cases (examples: unary opcodes in SDAG, FMA in IR) where we are trying (at least partially) to preserve exceptions without even asking if the target supports FP exceptions. Those should be corrected in subsequent patches. Real support for FP exceptions requires several changes to handle the constrained/strict FP ops. Differential Revision: https://reviews.llvm.org/D61331 llvm-svn: 359791
2019-05-02 22:47:59 +08:00
; CHECK-NEXT: mov x8, #9221120237041090560
[AArch64] add more tests for constant folding failures; NFC llvm-svn: 359592
2019-05-01 02:15:18 +08:00
; CHECK-NEXT: fmov d0, x8
; CHECK-NEXT: ret
%r = fsub double 0x7ff0000000000000, 0x7ff0000000000000
ret double %r
}
; Inf * 0.0 + ? --> NaN
define double @constant_fold_fma_nan(double* %p) {
; CHECK-LABEL: constant_fold_fma_nan:
; CHECK: // %bb.0:
[SelectionDAG] remove constant folding limitations based on FP exceptions We don't have FP exception limits in the IR constant folder for the binops (apart from strict ops), so it does not make sense to have them here in the DAG either. Nothing else in the backend tries to preserve exceptions (again outside of strict ops), so I don't see how this could have ever worked for real code that cares about FP exceptions. There are still cases (examples: unary opcodes in SDAG, FMA in IR) where we are trying (at least partially) to preserve exceptions without even asking if the target supports FP exceptions. Those should be corrected in subsequent patches. Real support for FP exceptions requires several changes to handle the constrained/strict FP ops. Differential Revision: https://reviews.llvm.org/D61331 llvm-svn: 359791
2019-05-02 22:47:59 +08:00
; CHECK-NEXT: mov x8, #9221120237041090560
; CHECK-NEXT: fmov d0, x8
[AArch64] add more tests for constant folding failures; NFC llvm-svn: 359592
2019-05-01 02:15:18 +08:00
; CHECK-NEXT: ret
%r = call double @llvm.fma.f64(double 0x7ff0000000000000, double 0.0, double 42.0)
ret double %r
}
declare double @llvm.fma.f64(double, double, double)