Richard Biener <rguent...@suse.de> writes:
> On May 8, 2020 4:28:24 PM GMT+02:00, Alexander Monakov <amona...@ispras.ru>
> wrote:
>>On Fri, 8 May 2020, Uros Bizjak wrote:
>>
>>> > Am I missing something?
>>>
>>> Is the above enough to declare min/max as IEEE compliant?
>>
>>No. SSE min/max instructions semantics match C expression x < y ? x :
>>y.
>>IEEE min/max operations are commutative when exactly one operand is a
>>NaN,
>>and so are C fmin/fmax functions:
>>
>> fmin(x, NaN) == fmin(NaN, x) == x // x is not a NaN
>>
>>In contrast, (x < y ? x : y) always returns y when x or y is a NaN, and
>>likewise the corresponding SSE instructions are not commutative.
>>
>>Therefore they are explicitly non-compliant in presence of NaNs.
>>
>>I don't know how GCC defines the semantics of GIMPLE min/max IFNs.
>
> The IFNs are supposed to match fmin and fmax from the C standard which IIRC
> have IEEE semantics.
Yeah, that was my understanding too (specifically the 2008 maxNum & minNum
rules, since new variants were added in 2019).
> Note the ISA likely behaves this way because it matches open coded C
> semantics.
>
> Arm folks added the IFNs so I have to dig up what exactly they were after...
We wanted it for pretty much exactly the kind of thing you're doing here:
having a vectorisable version of the C fmin and fmax functions. FWIW,
Alejandro posted a patch for reductions a while back:
https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513678.html
but it was posted during stage 3 and so kind-of stalled.
Like you say, the idea is that since the operation is commutative and
is the same in both vector and scalar form, there's no reason to require
any -ffast-math flags.
Thanks,
Richard
