Re: [PATCH] ppc: Use hard-float in ppc fp_hlper as early as possible...

[Richard Henderson]

On 5/4/20 12:29 PM, address@hidden wrote:

> Re: [PATCH] ppc: Use hard-float in ppc fp_hlper as early as possible. This 
> would increase the performance better than enable hard-float it in 
> soft-float.c; Just using fadd fsub fmul fdiv as a simple bench demo. With 
> this patch, performance are increased 2x. and 1.3x than the one enable 
> hard-float in soft-float.c Both version are not considerate inexact fp 
> exception yet.

Use a return after the one sentence title to separate it from the body of the
description.


>  float64 helper_fadd(CPUPPCState *env, float64 arg1, float64 arg2)
>  {
> +    CPU_DoubleU u1, u2;
> +
> +    u1.d = arg1;
> +    u2.d = arg2;
> +    CPU_DoubleU retDouble;
> +    retDouble.nd = u1.nd + u2.nd;
> +    if (likely(float64_is_zero_or_normal(retDouble.d)))
> +    {
> +        /* TODO: Handling inexact */
> +        return retDouble.d;
> +    }

First, you need to verify that the current rounding mode is
float_round_nearest_even.  Otherwise you are actively computing wrong results
for other rounding modes.

Second, including zero result in your acceptance test misses out on underflow
exceptions.

Third, what is your plan for inexact?  There's no point in continuing this
thread unless you fill in the TODO a bit more.

https://cafehayek.com/wp-content/uploads/2014/03/miracle_cartoon.jpg


r~