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

[Peter Maydell]

Oops, forgot to fix up Maciej's email address...

On 5 February 2015 at 16:37, Peter Maydell <address@hidden> wrote:
> 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]:

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