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

[Joseph Myers <joseph@codesourcery.com>]

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).

-- 
Joseph S. Myers
joseph@codesourcery.com