From: LIU Zhiwei <zhiwei_liu@c-sky.com>
To: Richard Henderson <richard.henderson@linaro.org>,
Alistair Francis <Alistair.Francis@wdc.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Chih-Min Chao <chihmin.chao@sifive.com>
Subject: Re: [PATCH 0/6] target/riscv: NaN-boxing for multiple precison
Date: Fri, 10 Jul 2020 15:03:04 +0800 [thread overview]
Message-ID: <2d2eb1ec-22fa-cf2c-9a45-ee954a23fa63@c-sky.com> (raw)
In-Reply-To: <0d484d59-ceeb-862b-4c44-e57065b914c0@linaro.org>
On 2020/7/8 23:35, Richard Henderson wrote:
> 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.
Get it.
The comment is moving both inputs check and the result nan-boxing code
to helper functions.
In my opinion, it doesn't matter whether put them into helper functions
or into translation functions.
More importantly, we should add inputs check and result nan-boxing for
all single float point instructions.
If you insist on we should move it to helper functions, I'd like to.:-)
Zhiwei
>
> r~
next prev parent reply other threads:[~2020-07-10 7:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 20:59 [PATCH 0/6] target/riscv: NaN-boxing for multiple precison LIU Zhiwei
2020-06-26 20:59 ` [PATCH 1/6] target/riscv: move gen_nanbox_fpr to translate.c LIU Zhiwei
2020-07-02 17:13 ` Richard Henderson
2020-06-26 20:59 ` [PATCH 2/6] target/riscv: NaN-boxing compute, sign-injection and convert instructions LIU Zhiwei
2020-07-02 17:15 ` Richard Henderson
2020-06-26 20:59 ` [PATCH 3/6] target/riscv: Check for LEGAL NaN-boxing LIU Zhiwei
2020-06-30 7:20 ` Chih-Min Chao
2020-06-30 7:31 ` LIU Zhiwei
2020-06-26 20:59 ` [PATCH 4/6] target/riscv: check before allocating TCG temps LIU Zhiwei
2020-07-02 17:13 ` Richard Henderson
2020-06-26 20:59 ` [PATCH 5/6] target/riscv: Flush not valid NaN-boxing input to canonical NaN LIU Zhiwei
2020-06-30 7:31 ` Chih-Min Chao
2020-06-30 7:37 ` LIU Zhiwei
2020-07-02 6:29 ` Chih-Min Chao
2020-06-26 20:59 ` [PATCH 6/6] target/riscv: clean up fmv.w.x LIU Zhiwei
2020-07-02 17:38 ` Richard Henderson
2020-06-26 21:21 ` [PATCH 0/6] target/riscv: NaN-boxing for multiple precison no-reply
2020-07-02 17:37 ` Richard Henderson
[not found] ` <3c139607-9cac-a28a-c296-b0e147b3b20f@c-sky.com>
2020-07-07 21:45 ` LIU Zhiwei
2020-07-08 15:35 ` Richard Henderson
2020-07-10 7:03 ` LIU Zhiwei [this message]
2020-07-10 16:03 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d2eb1ec-22fa-cf2c-9a45-ee954a23fa63@c-sky.com \
--to=zhiwei_liu@c-sky.com \
--cc=Alistair.Francis@wdc.com \
--cc=chihmin.chao@sifive.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).