On 2020/7/3 1:37, Richard Henderson wrote:
On 6/26/20 1:59 PM, LIU Zhiwei wrote:
Multiple precison shoule be supported by NaN-boxing. That means, we
should
flush not valid NaN-boxing input to canonical NaN before effective
calculation and we should NaN-boxing the result after the effective
calculation.
In this patch set, split the implementation to three steps for compute,
sign-injection, and some covert insns, which are check_nanboxed,
effective calculation and gen_nanbox_fpr.
Check_nanboxed checks the inputs and flushes not valid inputs to
cancical NaN.
Effective calculation is direct calculation on fp32 values.
Gen_nanbox_fpr does the NaN-boxing, writing the 1s to upper 32 bits.
I know I just reviewed a couple of these, but then I got to thinking
about
patch 3 more closely.
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?
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.
Since we must have a helper call for the actual fp arithmetic, we
might as well
put the rest of the logic in there too. That way the JIT code is
smaller.
Yes, we can. But I think it is clearer just let helper do calculation.
By the way, is there some advantages of smaller JIT code？
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？
I don't think so.
First, FMV.X.D can transfer any 64 bits value to float register.
Second, users may set invalid values to float register by GDB.
I think it's necessary to do the inputs check and result nan-boxing.
Zhiwei
Thoughts?
r~