llvm-project/llvm/test/CodeGen/ARM/fpcmp.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

72 lines
1.8 KiB
LLVM
Raw Normal View History

; RUN: llc -mtriple=arm-eabi -mattr=+vfp2 %s -o - | FileCheck %s
2008-02-18 04:02:20 +08:00
define i32 @f1(float %a) {
;CHECK-LABEL: f1:
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
;CHECK: vcmp.f32
;CHECK: movmi
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp olt float %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp1 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp1
}
2008-02-18 04:02:20 +08:00
define i32 @f2(float %a) {
;CHECK-LABEL: f2:
;CHECK: vcmp.f32
;CHECK: moveq
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp oeq float %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp2 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp2
}
2008-02-18 04:02:20 +08:00
define i32 @f3(float %a) {
;CHECK-LABEL: f3:
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
;CHECK: vcmp.f32
;CHECK: movgt
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp ogt float %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp3 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp3
}
2008-02-18 04:02:20 +08:00
define i32 @f4(float %a) {
;CHECK-LABEL: f4:
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
;CHECK: vcmp.f32
;CHECK: movge
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp oge float %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp4 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp4
}
2008-02-18 04:02:20 +08:00
define i32 @f5(float %a) {
;CHECK-LABEL: f5:
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
;CHECK: vcmp.f32
;CHECK: movls
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp ole float %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp5 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp5
}
2006-10-11 00:33:47 +08:00
2008-02-18 04:02:20 +08:00
define i32 @f6(float %a) {
;CHECK-LABEL: f6:
;CHECK: vcmp.f32
;CHECK: movne
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp une float %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp6 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp6
}
2008-02-18 04:02:20 +08:00
define i32 @g1(double %a) {
;CHECK-LABEL: g1:
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
;CHECK: vcmp.f64
;CHECK: movmi
2006-10-11 00:33:47 +08:00
entry:
2008-02-18 04:02:20 +08:00
%tmp = fcmp olt double %a, 1.000000e+00 ; <i1> [#uses=1]
%tmp7 = zext i1 %tmp to i32 ; <i32> [#uses=1]
ret i32 %tmp7
2006-10-11 00:33:47 +08:00
}