qemu-ppc
[Top][All Lists]
Advanced

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

Re: [PATCH v2 1/3] target/ppc: Fix FPSCR.FI bit being cleared when it sh


From: Rashmica Gupta
Subject: Re: [PATCH v2 1/3] target/ppc: Fix FPSCR.FI bit being cleared when it shouldn't
Date: Wed, 11 May 2022 20:12:02 +1000
User-agent: Evolution 3.42.4 (3.42.4-2.fc35)

Hello,

cc'ing Paul and Nick for clarification on the behaviour of xsrsp (see below)


On Tue, 2022-05-10 at 17:46 -0300, Víctor Colombo wrote:
> The FI bit in FPSCR is said to be a non-sticky bit on Power ISA.
> One could think this means that, if an instruction is said to modify
> the FPSCR register, the bit FI should be cleared. This is what QEMU
> does today.
> 
> However, the following inconsistency was found when comparing results
> from the hardware (tested on both a Power 9 processor and in
> Power 10 Mambo):
> 
> (FI bit is set before the execution of the instruction)
> Hardware: xscmpeqdp(0xff..ff, 0xff..ff) = FI: SET -> SET
> QEMU: xscmpeqdp(0xff..ff, 0xff..ff) = FI: SET -> CLEARED
> 
> This is happening to multiple instructions in the vsx
> implementations. As the FI bit is non-sticky, one could think that
> xscmpeqdp, a instruction the ISA states doesn't change FI bit, should
> result in a cleared FI. However, this is not happening on hardware.

I would think that if an instruction doesn't change a bit
then that instruction wouldn't clear or set that bit, regardless of if
that bit is sticky or not.

> 
> An investigation resulted in the following conclusion:
> If the ISA does not list the FI bit as altered for a particular
> instruction, then it should be kept as it was before the instruction.
> 
> QEMU is not following this behavior. Affected instructions include:
> - xv* (all vsx-vector instructions);
> - xscmp*, xsmax*, xsmin*;
> - xstdivdp and similars;
> (to identify the affected instructions, just search in the ISA for
>  the instructions that does not list FI in "Special Registers
> Altered")

The ISA does state 
"Floating-Point Fraction Inexact (FI)
This bit is set to 0 or 1 by VSX Scalar
Floating-Point Arithmetic, VSX Scalar Integer
Conversion, and VSX Scalar Round to
Floating-Point Integer class instructions to
indicate whether or not the rounded result is
inexact or the instruction caused a disabled
Overflow exception. See Section 7.3.2.6 on
page 524. This bit is not sticky."

So it seems that instruction classes like VSX Vector Round and VSX Vector
convert don't touch the FI bit.

> 
> Most instructions use the function do_float_check_status() to commit
> changes in the inexact flag. So the fix is to add a parameter to it
> that will control if the bit FI should be changed or not.
> All users of do_float_check_status() are then modified to provide
> this
> argument, controlling if that specific instruction changes bit FI or
> not.
> Some macro helpers are responsible for both instructions that change
> and instructions that aren't suposed to change FI. This seems to
> always
> overlap with the sfprf flag. So, reuse this flag for this purpose
> when
> applicable.
> 
> Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br>
> 
> ---
> 
> v2:
> - move the FI change from float_inexact_excp to do_float_check_status
> - sfprf will be renamed to sfifprf in another patch, as suggested by
>   Richard
> ---
>  target/ppc/cpu.h        |   2 +
>  target/ppc/fpu_helper.c | 122 +++++++++++++++++++++-----------------
> --
>  2 files changed, 66 insertions(+), 58 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 48596cfb25..901ded79e9 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -735,6 +735,8 @@ enum {
>                        (1 << FPSCR_VXSOFT) | (1 << FPSCR_VXSQRT) | \
>                        (1 << FPSCR_VXCVI))
>  
> +FIELD(FPSCR, FI, FPSCR_FI, 1)
> +
>  #define FP_DRN2         (1ull << FPSCR_DRN2)
>  #define FP_DRN1         (1ull << FPSCR_DRN1)
>  #define FP_DRN0         (1ull << FPSCR_DRN0)
> diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
> index f6c8318a71..f1ea4aa10e 100644
> --- a/target/ppc/fpu_helper.c
> +++ b/target/ppc/fpu_helper.c
> @@ -370,7 +370,6 @@ static inline void float_inexact_excp(CPUPPCState
> *env)
>  {
>      CPUState *cs = env_cpu(env);
>  
> -    env->fpscr |= FP_FI;
>      env->fpscr |= FP_XX;
>      /* Update the floating-point exception summary */
>      env->fpscr |= FP_FX;
> @@ -462,7 +461,8 @@ void helper_fpscr_check_status(CPUPPCState *env)
>      }
>  }
>  
> -static void do_float_check_status(CPUPPCState *env, uintptr_t raddr)
> +static void do_float_check_status(CPUPPCState *env, bool change_fi,
> +                                  uintptr_t raddr)
>  {
>      CPUState *cs = env_cpu(env);
>      int status = get_float_exception_flags(&env->fp_status);
> @@ -474,8 +474,10 @@ static void do_float_check_status(CPUPPCState
> *env, uintptr_t raddr)
>      }
>      if (status & float_flag_inexact) {
>          float_inexact_excp(env);
> -    } else {
> -        env->fpscr &= ~FP_FI; /* clear the FPSCR[FI] bit */
> +    }
> +    if (change_fi) {
> +        env->fpscr = FIELD_DP64(env->fpscr, FPSCR, FI,
> +                                !!(status & float_flag_inexact));
>      }


According to the ISA not all instructions that affect FI, set FI on an
inexact exception (xsrqpi apparently clears FI on an inexact exception
-- I have no idea if this actually happens on hardware).


>  
>      if (cs->exception_index == POWERPC_EXCP_PROGRAM &&
> @@ -490,7 +492,7 @@ static void do_float_check_status(CPUPPCState
> *env, uintptr_t raddr)
>  
>  void helper_float_check_status(CPUPPCState *env)
>  {
> -    do_float_check_status(env, GETPC());
> +    do_float_check_status(env, true, GETPC());
>  }
>  
    
... snip ...

> @@ -3195,7 +3201,7 @@ uint64_t helper_xsrsp(CPUPPCState *env,
> uint64_t xb)
>      uint64_t xt = do_frsp(env, xb, GETPC());
>  
>      helper_compute_fprf_float64(env, xt);
> -    do_float_check_status(env, GETPC());
> +    do_float_check_status(env, true, GETPC());
>      return xt;
>  }

I'm not clear what the behaviour of xsrsp should be. 

Section 7.4.5 Floating-Point Inexact Exception leads me to think it
shouldn't affect FI but the instruction definition indicates the
opposite. Maybe Paul or Nick can weigh in on this?


>  
> @@ -3355,7 +3361,7 @@ void helper_xsrqpi(CPUPPCState *env, uint32_t
> opcode,
>      }
>  
>      helper_compute_fprf_float128(env, t.f128);
> -    do_float_check_status(env, GETPC());
> +    do_float_check_status(env, true, GETPC());
>      *xt = t;
>  }
>  
> @@ -3408,7 +3414,7 @@ void helper_xsrqpxp(CPUPPCState *env, uint32_t
> opcode,
>  
>      helper_compute_fprf_float128(env, t.f128);
>      *xt = t;
> -    do_float_check_status(env, GETPC());
> +    do_float_check_status(env, true, GETPC());
>  }
>  
>  void helper_xssqrtqp(CPUPPCState *env, uint32_t opcode,
> @@ -3434,7 +3440,7 @@ void helper_xssqrtqp(CPUPPCState *env, uint32_t
> opcode,
>  
>      helper_compute_fprf_float128(env, t.f128);
>      *xt = t;
> -    do_float_check_status(env, GETPC());
> +    do_float_check_status(env, true, GETPC());
>  }
>  
>  void helper_xssubqp(CPUPPCState *env, uint32_t opcode,
> @@ -3460,5 +3466,5 @@ void helper_xssubqp(CPUPPCState *env, uint32_t
> opcode,
>  
>      helper_compute_fprf_float128(env, t.f128);
>      *xt = t;
> -    do_float_check_status(env, GETPC());
> +    do_float_check_status(env, true, GETPC());
>  }


All the other instruction helpers and definitions look correct to me.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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