mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
a7843cefbb
When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
26 lines
715 B
LLVM
26 lines
715 B
LLVM
; RUN: llc -mtriple arm-apple-darwin -filetype asm -o - %s | FileCheck -check-prefix CHECK-ARMv4 %s
|
|
; RUN: llc -mtriple armv7-apple-darwin -mcpu=cortex-a8 -filetype asm -o - %s | FileCheck -check-prefix CHECK-ARMv7 %s
|
|
|
|
define i32 @f7(float %a, float %b) {
|
|
entry:
|
|
%tmp = fcmp ueq float %a,%b
|
|
%retval = select i1 %tmp, i32 666, i32 42
|
|
ret i32 %retval
|
|
}
|
|
|
|
; CHECK-ARMv4-LABEL: f7:
|
|
; CHECK-ARMv4-DAG: bl ___eqsf2
|
|
; CHECK-ARMv4-DAG: bl ___unordsf2
|
|
; CHECK-ARMv4: cmp r0, #0
|
|
; CHECK-ARMv4: movne r0, #1
|
|
; CHECK-ARMv4: orrs r0, r0,
|
|
; CHECK-ARMv4: moveq r0, #42
|
|
|
|
; CHECK-ARMv7-LABEL: f7:
|
|
; CHECK-ARMv7: vcmp.f32
|
|
; CHECK-ARMv7: vmrs APSR_nzcv, fpscr
|
|
; CHECK-ARMv7: movweq
|
|
; CHECK-ARMv7-NOT: vmrs
|
|
; CHECK-ARMv7: movwvs
|
|
|