Re: [RFC PATCH] softfloat: Allow runtime choice of default NaN value

[Richard Henderson <richard.henderson@linaro.org>]

On 11/28/24 08:54, Peter Maydell wrote:
> Currently we hardcode the default NaN value in parts64_default_nan()
> using a compile-time ifdef ladder. This is awkward for two cases:
>   * for single-QEMU-binary we can't hard-code target-specifics like this
>   * for Arm FEAT_AFP the default NaN value depends on FPCR.AH
>     (specifically the sign bit is different)
> 
> Add a field to float_status to specify the default NaN value; fall
> back to the old ifdef behaviour if these are not set.
> 
> The default NaN value is specified by setting a uint8_t to a
> pattern corresponding to the sign and upper fraction parts of
> the NaN; the lower bits of the fraction are set from bit 0 of
> the pattern.
> 
> This is an RFC to ask for opinions on whether this is the right
> way to let the target set its default NaN. I can't decide whether
> I think encoding it into a uint8_t like that is clever, or merely
> too clever :-)

I think that's perfectly fine.

>   #elif defined(TARGET_HEXAGON)
> -    sign = 1;
> -    frac = ~0ULL;
> +        /*
> +         * Sign bit set, all frac bits set. This is an odd special case,
> +         * where our value doesn't match up with the snan_bit_is_one setting.
> +         * This is because for Hexagon the returned value is always -1,
> +         * not a real NaN value.
> +         */
> +        dnan_pattern = 0b11111111;

It's a real (signalling) nan value -- the oddity is that the default nan is not quiet.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~