On Wed, Oct 13, 2021 at 10:29:26AM +0200, Richard Biener wrote:
> On Wed, Oct 13, 2021 at 9:43 AM HAO CHEN GUI <guih...@linux.ibm.com> wrote:
> > As to IEEE behavior, do you mean "Minimum and maximum operations"
> > defined in IEEE-754 2019? If so, I think VSX/altivec min/max instructions
> > don't conform with it. It demands a quite NaN if either operand is a NaN
> > while our instructions don't.
> >
> > IEEE-754 2019 maximum(x, y) is xif x>y, yif y>x, and a quiet NaN if either
> > operand is a NaN, according to 6.2. For this operation, +0 compares greater
> > than −0. Otherwise (i.e., when x=y and signs are the same) it is either xor
> > y. Actions for xvmaxdp
>
> Hmm, then I do not understand the reason for the patch - people using
> the intrinsics cannot expect IEEE semantics then.
> So you are concerned that people don't get the 1:1 machine instruction
> but eventually the IEEE conforming MIN/MAX_EXPR?
I do not know about Gimple MIN_EXPR (it is not documented?), but the
RTL "smin" is meaningless in the presence of NaNs or signed zeros. This
is documented (in rtl.texi):
"""
@findex smin
@findex smax
@cindex signed minimum
@cindex signed maximum
@item (smin:@var{m} @var{x} @var{y})
@itemx (smax:@var{m} @var{x} @var{y})
Represents the smaller (for @code{smin}) or larger (for @code{smax}) of
@var{x} and @var{y}, interpreted as signed values in mode @var{m}.
When used with floating point, if both operands are zeros, or if either
operand is @code{NaN}, then it is unspecified which of the two operands
is returned as the result.
"""
(not exactly meaningless, okay, but not usable for almost anything).
> But that can then still happen with -ffast-math so I wonder what's the point.
That :-)
Segher
