Re: [RFC PATCH v2 5/7] target/ppc: Implemented xvf16ger*

[Richard Henderson]

On 5/6/22 07:18, Lucas Mateus Castro(alqotel) wrote:
> +static inline float32 float32_neg(float32 a)
> +{
> +    if (((a & 0x7f800000) == 0x7f800000) && (a & 0x007fffff)) {
> +        return a;
> +    } else {
> +        return float32_chs(a);
> +    }
> +}

This is wrong -- even NaNs get their signs changed.
Negation and absolute value are non-arithmetic operations.

If you're matching hardware results, this suggests...

> +                    if (neg_mul) {
> +                        msum = float32_neg(msum);
> +                    }
> +                    if (neg_acc) {
> +                        aux_acc = float32_neg(at[i].VsrSF(j));
> +                    } else {
> +                        aux_acc = at[i].VsrSF(j);
> +                    }
> +                    at[i].VsrSF(j) = float32_add(msum, aux_acc, excp_ptr);

This "add" should be "sub" instead of using a separate negation, when required.
I do wonder about the double-negation vs nans.

It looks like this could be

  float32_muladd(float32_one, msum, aux_acc, flags, &status)

with flags set to float_muladd_negate_* for neg_mul and neg_acc.  Any NaNs would go 
through pick_nan_muladd and fail to be altered.

I'm not sure if I'm suggesting actual use of muladd, for the simplicity, or if you should 
have an inline check for nans.  I might need to think about this in the morning.


r~