https://llvm.org/bugs/show_bug.cgi?id=27363
Bug ID: 27363
Summary: @llvm.maxnum.* does not handle signaling NaNs the same
way as IEEE 754-2008
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: stokl...@2pi.dk
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The @llvm.maxnum.* intrinsic is documented like this:
> Follows the IEEE-754 semantics for maxNum, which also match for libm’s fmax.
>
> If either operand is a NaN, returns the other non-NaN operand.
> Returns NaN only if both operands are NaN.
If one operand is a signaling NaN, this behavior doesn't match IEEE 754-2008:
@llvm.maxnum.f64(1.0, qNaN) -> 1.0
@llvm.maxnum.f64(1.0, sNaN) -> 1.0
IEEE 754-2008:
maxNum(1.0, qNaN) -> 1.0
maxNum(1.0, sNaN) -> qNaN
I wonder if this changed in the 2008 revision?
The Aarch64 backend translates an fmax() library call to an fmaxnm instruction
which has the 754-2008 semantics for signaling NaNs.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
