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

[Hal Finkel via llvm-dev]

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>