Re: [RFC PATCH v2 7/7] target/ppc: Implemented [pm]xvbf16ger2*

[Lucas Mateus Martins Araujo e Castro]

On 08/05/2022 01:27, Richard Henderson wrote:

> On
>       5/6/22 07:18, Lucas Mateus Castro(alqotel) wrote:
>       
> >         There's a discrepancy between this implementation and mambo/the
> >         
> >         hardware where implementing it with float64_mul then
> >         float64r32_muladd
> >         
> >         sometimes results in an incorrect result after an underflow, but
> >         
> >         implementing with float32_mul then float32_muladd results in
> >         incorrect
> >         
> >         signal in some 0 or infinite results. I've not been able to
> >         solve this
> >         
> >       
>       
>       I did suggest that the float64_mul needs to be done in
>       round-to-odd.
>       
>

From what I understood, you meant:

        rmode = get_float_rounding_mode(&status);
        set_float_rounding_mode(float_round_to_odd, &status);
        psum = float64_mul(va, vb, &status);
        set_float_rounding_mode(rmode, &status);
        psum = float64r32_muladd(vc, vd, psum, 0, &status);

Which doesn't solve the problem, I tried other solutions but overall I found 3 test cases that no solution could pass all, those being:

xa = 0x 000923da 28c31f00 00018540 XXXXXXXX
xb = 0x 9d080000 000f97ac b7092f00 XXXXXXXX
xvbf16ger2 at, xa, xb
at = 0x 80000000 XXXXXXXX XXXXXXXX XXXXXXXX
        0xXXXXXXXX 80000016 XXXXXXXX XXXXXXXX
        0xXXXXXXXX XXXXXXXX 80000001 XXXXXXXX
        0xXXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Doing the operation either with float64 (with and without round_to_odd) or with a new softfloat operation that uses FloatParts64 results in 0x80000015 instead of 0x80000016, but doing it with float32 results in 0x00000000 instead of 0x80000000 and 0x80000002 instead of 0x80000001

Between those choices I'd go with float64 as to keep the result numerically close tho the actual value if the next operation treat those as an integer (with float32 you can end up having 0 instead of INT32_MIN) and the results are close if they're treated as floating-point.

>       
>       Anyway, for this patch,
>       
>       Reviewed-by: Richard Henderson
>       <richard.henderson@linaro.org>
>       
>       
>       
>       r~
>       
>

--
Lucas Mateus M. Araujo e Castro
Instituto de Pesquisas ELDORADO
Departamento Computação Embarcada
Analista de Software Trainee
Aviso Legal - Disclaimer