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.