Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

[Peter Maydell]

On 9 December 2014 at 01:54, Maciej W. Rozycki <address@hidden> wrote:
> Fix sNaN handling in floating-point format conversion operations, that
> are classified by the IEEE 754-2008 standard as general-computational
> operations [1]:
>
> "5.4 formatOf general-computational operations
>
> "5.4.2 Conversion operations for floating-point formats and decimal
> character sequences
>
> "Implementations shall provide the following formatOf conversion
> operations from all supported floating-point formats to all supported
> floating-point formats, as well as conversions to and from decimal
> character sequences.  These operations shall not propagate non-canonical
> results.  Some format conversion operations produce results in a
> different radix than the operands."
>
> according to the quietening requirement [2] set by the same standard:
>
> "7.2 Invalid operation
>
> "For operations producing results in floating-point format, the default
> result of an operation that signals the invalid operation exception
> shall be a quiet NaN that should provide some diagnostic information
> (see 6.2).
>
> "These operations are:
>     a)   any general-computational or signaling-computational operation
>          on a signaling NaN (see 6.2), except for some conversions (see
>          5.12)"
>
> and the reference above is [3]:
>
> "5.12 Details of conversion between floating-point data and external
> character sequences"
>
> so does not apply to conversions a pair of floating-point formats.
>
> Therefore quieten any sNaN encountered in floating-point format
> conversions, in the usual manner.
>
> References:
>
> [1] "IEEE Standard for Floating-Point Arithmetic", IEEE Computer
>     Society, IEEE Std 754-2008, 29 August 2008, pp. 21-22
>
> [2] same, p. 37
>
> [3] same, p. 30
>
> Signed-off-by: Maciej W. Rozycki <address@hidden>
> ---
>  This is in particular how MIPS hardware operates, other processors
> supposedly do the same if they claim compliance to IEEE 754.

ARM currently handles this issue by calling the _maybe_silence_nan()
function in all target-specific helper functions that call
float-to-float conversion functions (but that has its own
issues, see below).

Have you looked at the other architectures that use these
functions to convert float values to see what their NaN
handling semantics are? I agree about what the spec says,
but we may well have targets which are not fully IEEE
compliant and rely on the current semantics (x86 springs to
mind).

Also in this area, ARM has a problem where we don't give the
correct answers for fp-to-fp conversions from a higher precision
to a lower precision where the input is a signaling NaN whose
non-zero mantissa bits are all at the low end such that the
truncation of the mantissa into the lower precision format
would drop them all. The result is the wrong value of quiet NaN
(we return the default NaN, which has the sign bit clear, but the
FPConvertNaN pseudocode specifies that we should effectively get
the default NaN but with the same sign bit as the input SNaN).

I think this means that:
 (1) we want to put handling of silencing the signaling NaNs
 into the NaN conversion functions themselves (since it's
 too late to do it correctly once the commonNaNtoFloat16
 function has thrown away data)
 (2) that handling needs to be target specific, as most details
 of quiet vs signaling NaNs are

I note in passing that the float*ToCommonNaN and commonNaNToFloat*
functions are used only in the back-to-back call sequence of
   return commonNaNToFloatX(floatYToCommonNaN(...))
for handling the NaN inputs on FP-to-FP conversion.

thanks
-- PMM