On Mon, 11 May 2020, Joseph Myers wrote:
> On Fri, 8 May 2020, Richard Biener wrote:
>
> > The IFNs are supposed to match fmin and fmax from the C standard which
> > IIRC have IEEE semantics.
>
> fmin and fmax have IEEE (2008) semantics (where an sNaN operand results in
> a qNaN result with "i
On Fri, 8 May 2020, Richard Biener wrote:
> The IFNs are supposed to match fmin and fmax from the C standard which
> IIRC have IEEE semantics.
fmin and fmax have IEEE (2008) semantics (where an sNaN operand results in
a qNaN result with "invalid" raised", but a quiet NaN results in the other
o
Richard Biener writes:
> On Mon, 11 May 2020, Alexander Monakov wrote:
>
>> On Mon, 11 May 2020, Richard Sandiford wrote:
>>
>> > 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-mat
On Mon, 11 May 2020, Alexander Monakov wrote:
> On Mon, 11 May 2020, Richard Sandiford wrote:
>
> > 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.
>
> Note that PR88540
On Mon, 11 May 2020, Richard Sandiford wrote:
> 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.
Note that PR88540 that Richard is referencing uses open-coded x < y ? x : y
(no
Richard Biener writes:
> On May 8, 2020 4:28:24 PM GMT+02:00, Alexander Monakov
> 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 <
On Sun, 10 May 2020, Uros Bizjak wrote:
> So, I found [1], that tries to explain this issue.
>
> [1] https://2pi.dk/2016/05/ieee-min-max
I would also recommend reading this report that covers a few more
architectures and issues with IEEE754 definitions:
http://grouper.ieee.org/groups/msc/ANS
On Fri, May 8, 2020 at 4:38 PM Richard Biener wrote:
>
> On May 8, 2020 4:28:24 PM GMT+02:00, Alexander Monakov
> 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 instruc
On May 8, 2020 4:28:24 PM GMT+02:00, Alexander Monakov
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 operatio
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/f
On Fri, May 8, 2020 at 3:46 PM Alexander Monakov wrote:
>
>
>
> On Fri, 8 May 2020, Richard Biener wrote:
>
> >
> > Currently we fail to optimize those which are used when MIN/MAX_EXPR
> > cannot be used for FP values but the target has IEEE conforming
> > implementations.
>
> i386 ieee_s{min,max}
On Fri, 8 May 2020, Richard Biener wrote:
>
> Currently we fail to optimize those which are used when MIN/MAX_EXPR
> cannot be used for FP values but the target has IEEE conforming
> implementations.
i386 ieee_s{min,max} patterns are definitely not IEEE-compliant,
their comment alludes to tha
On Fri, May 8, 2020 at 3:02 PM Richard Biener wrote:
>
>
> Currently we fail to optimize those which are used when MIN/MAX_EXPR
> cannot be used for FP values but the target has IEEE conforming
> implementations.
>
> This patch adds support for fmin/fmax detection to phiopt and
> makes the named p
13 matches
Mail list logo
