Re: [PATCH 0/6] target/riscv: NaN-boxing for multiple precison

[Richard Henderson]

On 7/7/20 2:45 PM, LIU Zhiwei wrote:
>> On 2020/7/3 1:37, Richard Henderson wrote:
>>> I think it would be better to do all of the nan-boxing work inside of the
>>> helpers, including the return values.
>> Do you mean a helper function just for nan-boxing work?

No, that's not what I mean.

>> I don't think so.
>>
>> The inputs are flushed to canonical NAN only when they are
>> not legal nan-boxed values.
>>
>> The result is nan-boxed before writing  to  destination register.
>>
>> Both of them have some relations to nan-boxing, but they are not the same.

I mean

uint64_t helper_fadd_s(CPURISCVState *env, uint64_t frs1,
                       uint64_t frs2)
{
    float32 in1 = check_nanbox(frs1);
    float32 in2 = check_nanbox(frs2);
    float32 res = float32_add(in1, in2, &env->fp_status);

    return gen_nanbox(res);
}

I.e., always require nan-boxed inputs and return a nan-boxed output.

>>> If, for RVF && !RVD, we always maintain the invariant that the values are
>>> nanboxed anyway, then we do not even have to check for RVD at runtime.
>> Do you mean if FMV.X.S and FLW are nan-boxed, then we will not get the
>> invalid values？

No, I mean that if !RVD, there is no way to put an unboxed value into the fp
registers because...

>> First, FMV.X.D can transfer any 64 bits value to float register.
>> Second, users may set  invalid values  to float register by GDB.

... FMV.X.D does not exist for !RVD, nor does FLD.

The check_nanbox test will always succeed for !RVD, so we do not need to check
that RVD is set before performing check_nanbox.

Because the check is inexpensive, and because we expect !RVD to be an unusual
configuration, we do not bother to provide a second set of helpers that do not
perform the nan-boxing.


r~