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~
