Re: [PATCH] Skip constant folding for fmin/max when either argument is sNaN [PR105414]

[Richard Biener <richard.guenther@gmail.com>]

On Thu, May 5, 2022 at 7:11 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
>
> > MIN/MAX_EXPR shouldn't even appear with -fsignalling-nans for this
> > reason, at least that's what I thought.  But yes, you might have a point
> > here (but maybe it's also not strictly enough specified).  One option would
> > be to do (minmax == MAX_EXPR || minmax == MIN_EXPR || !tree_expr ...)
> >
> > Joseph - are MIN_EXPR and MAX_EXPR supposed to turn sNaN into qNaN
> > and the 'undefinedness' is merely as to which operand is chosen?
>
> I don't know what MIN_EXPR and MAX_EXPR are supposed to do with sNaN
> arguments.  As noted, the fmax and fmin functions should produce a qNaN
> result with the "invalid" exception raised (so with an sNaN argument, it's
> definitely not valid to fold them in the absence of -fno-trapping-math;
> with -fsignaling-nans -fno-trapping-math, if an argument is known to be
> sNaN it would be valid to fold to qNaN, but I doubt there's much use of
> that option combination).
>
> C never attempts to define which qNaN result (choice of payload or sign
> bit) is produced by an operation and I don't think our optimizations
> should be trying to define that (with any command-line options currently
> supported) either (other than for non-computational operations such as
> fabs and copysign, but even there there is scope for
> implementation-defined handling of assignment as a convertFormat operation
> rather than a copy operation).  Note that while some architectures
> propagate NaN payloads from a NaN operand to an instruction, others (e.g.
> RISC-V) do not, and when payloads are propagated there would still be the
> matter of which payload is chosen when there is more than one NaN operand
> (on x86, that is handled differently for SSE and x87 instructions).

Thanks.  So I think the patch as posted is correct on the safe side in
letting the CPU to decide what happens with sNaNs.  As said, the chance
seeing an sNaN and MAX/MIN_EXPR is low.

So I'm defering to the poster if he wants to re-post with treating MIN/MAX_EXPR
special in the optimistic sense.

Richard.


> --
> Joseph S. Myers
> joseph@codesourcery.com