On Fri, May 8, 2020 at 3:46 PM Alexander Monakov <amona...@ispras.ru> 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} patterns are definitely not IEEE-compliant,
> their comment alludes to that:
>
> ;; These versions of the min/max patterns implement exactly the operations
> ;; min = (op1 < op2 ? op1 : op2)
> ;; max = (!(op1 < op2) ? op1 : op2)
> ;; Their operands are not commutative, and thus they may be used in the
> ;; presence of -0.0 and NaN.
>
> I don't understand why the patch is correct if the IFNs refer to fully
> IEEE-compliant operations (which is in itself a bit ambiguous w.r.t
> behavior when exactly one operand is a NaN).
The comment says that they may be used in the presence of -0.0 and
NaN. Further, ISA says for e.g. maxpd:
Performs a SIMD compare of the packed double-precision floating-point
values in the first source operand and the
second source operand and returns the maximum value for each pair of
values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value
in the second operand (source operand) is
returned. If a value in the second operand is an SNaN, then SNaN is
forwarded unchanged to the destination (that
is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the
second operand (source operand), either a NaN
or a valid floating-point value, is written to the result. If instead
of this behavior, it is required that the NaN source
operand (from either the first or second operand) be returned, the
action of MAXPD can be emulated using a
sequence of instructions, such as a comparison followed by AND, ANDN and OR.
> Am I missing something?
Is the above enough to declare min/max as IEEE compliant?
Uros.
