[llvm-dev] RFC: What is the real behavior for the minnum/maxnum intrinsics?

[Alex Bradbury via llvm-dev]

On 23 July 2018 at 11:56, Arsenault, Matthew via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
>
> The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear
> right now to usefully optimize. There are two problems. First the expected
> behavior for signaling NaNs needs to be clarified. Second, whether the
> returned value is expected to be canonicalized (as if by llvm.canonicalize).
>
> Currently according to the LangRef:
>
> Follows the IEEE-754 semantics for minNum, which also match for libm's
> fmin.
>
> If either operand is a NaN, returns the other non-NaN operand. Returns
> NaN only if both operands are NaN. If the operands compare equal,
> returns a value that compares equal to both operands. This means that
> fmin(+/-0.0, +/-0.0) could return either -0.0 or 0.0.
>
> This first line is a lie. This isn’t true for the case of signaling NaNs.
> The IEEE rule is if either input is a signaling nan, it returns a quieted
> NaN, not the other operand. The C standard definition for fmin/fmax do not
> make this distinction, and just return the other operand.

Sadly I can't seem to find an actual copy of the draft of the IEEE
754-201x standard, but I understand that it introduces new min/max
functions that better match the min/max actually implemented by
hardware and used in languages
<https://github.com/WebAssembly/design/issues/214>. I agree, the first
sentence you quote doesn't seem correct. Perhaps someone more familiar
with the IEEE 754 development can give more insight.

Best,

Alex