Re: [PULL v2 15/31] Hexagon (target/hexagon) use softfloat default NaN and tininess

[Peter Maydell]

On Sun, 2 May 2021 at 15:44, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> From: Taylor Simpson <tsimpson@quicinc.com>
>
> Suggested-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Message-Id: <1617930474-31979-11-git-send-email-tsimpson@quicinc.com>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

> diff --git a/fpu/softfloat-specialize.c.inc b/fpu/softfloat-specialize.c.inc
> index c2f87addb2..9ea318f3e2 100644
> --- a/fpu/softfloat-specialize.c.inc
> +++ b/fpu/softfloat-specialize.c.inc
> @@ -145,6 +145,9 @@ static FloatParts parts_default_nan(float_status *status)
>  #elif defined(TARGET_HPPA)
>      /* snan_bit_is_one, set msb-1.  */
>      frac = 1ULL << (DECOMPOSED_BINARY_POINT - 2);
> +#elif defined(TARGET_HEXAGON)
> +    sign = 1;
> +    frac = ~0ULL;
>  #else
>      /* This case is true for Alpha, ARM, MIPS, OpenRISC, PPC, RISC-V,
>       * S390, SH4, TriCore, and Xtensa.  I cannot find documentation

This change has the effect that Hexagon is unique in that its
default_nan value doesn't correspond with its setting for
snan_bit_is_one(): the default NaN is supposed to be
a QNaN but this value is what snan_bit_is_one() thinks is an SNaN.

Is that intentional? Should we adjust snan_bit_is_one() too ?

(I noticed this because I need to make the default-nan value
be runtime-selectable, and was wondering if I could avoid
having to make targets specify snan_bit_is_one separately
from specifying their default-NaN value. But this handling
of Hexagon would prevent that.)

thanks
-- PMM