qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/3] target-ppc: simplify NaN propagation for


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 1/3] target-ppc: simplify NaN propagation for vector functions
Date: Wed, 20 Apr 2011 13:04:48 +0100

On 20 April 2011 12:32, Aurelien Jarno <address@hidden> wrote:
> Commit e024e881bb1a8b5085026589360d26ed97acdd64 provided a pickNaN()
> function for PowerPC, implementing the correct NaN propagation rules.
> Therefore there is no need to test the operands manually, we can rely
> on the softfloat code to do that.
>
> Cc: Alexander Graf <address@hidden>
> Signed-off-by: Aurelien Jarno <address@hidden>
> ---
>  target-ppc/op_helper.c |   26 +++++++-------------------
>  1 files changed, 7 insertions(+), 19 deletions(-)
>
> Note: Unfortunately the current propagation rules implemented in
> softfloat only concerns 2 operands operations, so we have to keep
> HANDLE_NAN3 for now.

These first two patches remove all of the uses of HANDLE_NAN1 and
HANDLE_NAN2, so we can just delete those macro definitions, right?

You could clean up DO_HANDLE_NAN a little:

#define DO_HANDLE_NAN(result, x)               \
    if (float32_is_any_nan(x)) {               \
        result = float32_maybe_silence_nan(x); \
    } else

On a slight tangent:

I need to add ARM support for fused multiply-accumulate (vfma,vfms),
so perhaps in the long run it would be better to make them softfloat
primitives? (they are after all in the new IEEE spec, so they're in
softfloat's domain in some sense.) That would move the 'propagate one
of 3 NaNs' logic into softfloat.

(I suspect that implementing fused-mac by doing intermediate results
mas float64 will set the Inexact bit for some cases where the hardware
will not, but I haven't thought too deeply about it yet.)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]