qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] riscv: Format Rd of FMV.W.X with NoN-boxing


From: Richard Henderson
Subject: Re: [PATCH] riscv: Format Rd of FMV.W.X with NoN-boxing
Date: Wed, 22 Jan 2020 07:10:54 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 1/21/20 11:53 PM, Ian Jiang wrote:
> --
> Ian Jiang
> 
> Richard Henderson <address@hidden> 于2020年1月22日周三 下午4:53写道:
>>
>> On 1/21/20 9:24 PM, Ian Jiang wrote:
>>> For FMV.W.X that moves the lower 32 bits of an integer register to a
>>> floating-point register, Rd should encoded with NoN-boxing scheme.
>>> Note: This applies to RV64 only.
>>>
>>> Signed-off-by: Ian Jiang <address@hidden>
>>> ---
>>>  target/riscv/insn_trans/trans_rvf.inc.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/target/riscv/insn_trans/trans_rvf.inc.c 
>>> b/target/riscv/insn_trans/trans_rvf.inc.c
>>> index 172dbfa919..62b7a36567 100644
>>> --- a/target/riscv/insn_trans/trans_rvf.inc.c
>>> +++ b/target/riscv/insn_trans/trans_rvf.inc.c
>>> @@ -368,6 +368,7 @@ static bool trans_fmv_w_x(DisasContext *ctx, 
>>> arg_fmv_w_x *a)
>>>
>>>  #if defined(TARGET_RISCV64)
>>>      tcg_gen_mov_i64(cpu_fpr[a->rd], t0);
>>> +    tcg_gen_ori_i64(cpu_fpr[a->rd], cpu_fpr[a->rd], 0xffffffff00000000ULL);
>>>  #else
>>>      tcg_gen_extu_i32_i64(cpu_fpr[a->rd], t0);
>>>  #endif
>>>
>>
>> This doesn't look right.  There's nothing in the spec that says the 
>> nan-boxing
>> is restricted to rv64.  NaN-boxing is all about FLEN, not XLEN.
>>
> 
> Why the translation of FLW has a NaN-boxing?
> 
> file ./target/riscv/insn_trans/trans_rvf.inc.c
>  26 static bool trans_flw(DisasContext *ctx, arg_flw *a)
>  27 {
> ...
>  34     tcg_gen_qemu_ld_i64(cpu_fpr[a->rd], t0, ctx->mem_idx, MO_TEUL);
>  35     /* RISC-V requires NaN-boxing of narrower width floating point values 
> */
>  36     tcg_gen_ori_i64(cpu_fpr[a->rd], cpu_fpr[a->rd], 
> 0xffffffff00000000ULL);
> ...
>  41 }

Eh?  Obviously because we're loading a 32-bit value into a FLEN=64 bit register.

(Except when we've selected a cpu without RVD, I suppose, but in that case this
nan-boxing is both harmless and invisible.)


r~



reply via email to

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