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

[Stephen Canon via llvm-dev]

> On Jul 23, 2018, at 3:40 PM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 23 July 2018 at 11:56, Arsenault, Matthew via llvm-dev
> <llvm-dev at lists.llvm.org <mailto: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 <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.

It’s a bit more subtle.

The minNum, maxNum, minNumMag, and maxNumMag operations have been removed from the normative clauses of IEEE 754 201x entirely, and replaced with a set of non-normative recommended operations. This is not a great situation, because it doesn’t provide much clarity for complier writers or CPU architects, but it at least removes the existing operations which were known to be critically flawed, due to them not being associative.

The new non-normative operations of interest are defined in clause 9.6:

1. minimum / maximum: returns NaN if any input is NaN.
2. minimumNumber / maximumNumber: return NaN only if *every* input is NaN, even if signaling NaNs are present.

Otherwise returns the numerical min / max **ordering –0 before +0**. The behavior of ordering zeros is a critical distinction from the behavior of the old operations, possibly more critical than the signaling NaN behavior.

I can’t in good faith recommend jumping to implement these semantics, because they are non-normative. They make sense, but there are other definitions that make sense as well, so there’s no guarantee that IEEE 754 won’t tweak them before adopting them in a normative clause in the next revision. I can’t really argue against adopting them either, because they do make perfect sense.

Some notes on how these definitions align with existing architectures of interest:

ARMv8:
1. FMIN / FMAX implement the new minimum / maximum exactly.
2. FMINNM / FMAXNM implement minimumNumber / maximumNumber if we can prove no sNaNs are present. If sNaN may be present, we need to canonicalize each argument first.

X86:
1. AFAIK there’s no trivial instruction for minimum / maximum, because MINxx / MAXxx return the second argument if either is NaN. So this will look like a compare + min/max + select, I think.
2. The new AVX-512 VRANGExx can be used to implement minimumNumber / maximumNumber if we can prove no sNaNs are present. If sNaN may be present, we need to canonicalize each argument first. Pre-AVX-512, this is also compare + min/max + select.

Someone else will need to provide details for other arches.
– Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180726/31ca1ce2/attachment.html>