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

> 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>

> On Jul 26, 2018, at 18:51, Stephen Canon via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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.
> 
The AMDGPU instructions in the default mode for compute match #2 here. They also
do seem to preserve the new signed 0 behavior.

If we can settle on stating explicitly the in the LangRef that de-facto current
behavior where the signalingness of a NaN is ignored here, that would allow
solving my immediate problems. The required lowering code would be clear and
optimizable. This isn’t ideal but at as far as the current standard is
concerned, this fits with sNaN being generally broken in LLVM (e.g. constant
folding for every operation doesn’t bother quieting them)

This is the only part that I immediately care about. When the new standard is
finalized, we can re-visit the other details such as the signed 0 question. Are
there any targets that don’t already treat -0.0 as < 0.0?

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180727/1c19ad31/attachment.html>

> On Jul 27, 2018, at 4:20 AM, Matt Arsenault <arsenm2 at gmail.com>
wrote:
> 
> This is the only part that I immediately care about. When the new standard
is finalized, we can re-visit the other details such as the signed 0 question.
Are there any targets that don’t already treat -0.0 as < 0.0?
[V]MINxx and [V]MAXxx on x86 return the second argument if the arguments compare
equal (but they also don’t handle NaNs “correctly” — they’re really intended to
pattern match (a < b ? a : b) instead of the fmin / fmax libm functions.

The newer AVX-512 VRANGExx functions get the sign of zero right.

– Steve

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

On 07/27/2018 03:20 AM, Matt Arsenault via llvm-dev
wrote:
>
>
>> On Jul 26, 2018, at 18:51, Stephen Canon via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>> 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.
>>
>
> The AMDGPU instructions in the default mode for compute match #2 here.
> They also do seem to preserve the new signed 0 behavior.
>
> If we can settle on stating explicitly the in the LangRef that
> de-facto current behavior where the signalingness of a NaN is ignored
> here, that would allow solving my immediate problems.
Given that I believe we don't generally support SNaN currently, this
seems consistent to me.

 -Hal
> The required lowering code would be clear and optimizable. This isn’t
> ideal but at as far as the current standard is concerned, this fits
> with sNaN being generally broken in LLVM (e.g. constant folding for
> every operation doesn’t bother quieting them)
>
> This is the only part that I immediately care about. When the new
> standard is finalized, we can re-visit the other details such as the
> signed 0 question. Are there any targets that don’t already treat -0.0
> as < 0.0?
>
> -Matt
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180729/993bb956/attachment.html>