From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFA35C433E0 for ; Thu, 6 Aug 2020 12:11:33 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8F22C221E5 for ; Thu, 6 Aug 2020 12:11:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F22C221E5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=c-sky.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k3ck8-0000Vj-UD for qemu-devel@archiver.kernel.org; Thu, 06 Aug 2020 06:03:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57540) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k3cjR-00005O-OE; Thu, 06 Aug 2020 06:02:41 -0400 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:60679) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k3cjM-0001wd-Sc; Thu, 06 Aug 2020 06:02:41 -0400 X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06887019|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.0302796-0.00234627-0.967374; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16368; MF=zhiwei_liu@c-sky.com; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.IDMK18c_1596708147; Received: from 30.225.208.44(mailfrom:zhiwei_liu@c-sky.com fp:SMTPD_---.IDMK18c_1596708147) by smtp.aliyun-inc.com(10.147.42.197); Thu, 06 Aug 2020 18:02:28 +0800 Subject: Re: [PATCH v2 1/7] target/riscv: Generate nanboxed results from fp helpers To: Chih-Min Chao References: <20200724002807.441147-1-richard.henderson@linaro.org> <20200724002807.441147-2-richard.henderson@linaro.org> <1aa6cb56-2f41-45c1-2d32-ec8b3b10780b@c-sky.com> <9e10c17c-7a9e-5f7f-b1e3-c195d4e30b32@linaro.org> <4183e2c5-9a9b-2416-301d-95e62ac53a6c@c-sky.com> From: LIU Zhiwei Message-ID: <0631dbf2-9373-8ec6-f20b-1d5d137a7028@c-sky.com> Date: Thu, 6 Aug 2020 18:02:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C4674CC0C5E7928B9A8680B7" Content-Language: en-US Received-SPF: none client-ip=121.197.200.217; envelope-from=zhiwei_liu@c-sky.com; helo=smtp2200-217.mail.aliyun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/06 06:02:29 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Frank Chang , Alistair Francis , Richard Henderson , "qemu-devel@nongnu.org Developers" , "open list:RISC-V" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" This is a multi-part message in MIME format. --------------C4674CC0C5E7928B9A8680B7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2020/8/6 16:42, Chih-Min Chao wrote: > > > > On Thu, Aug 6, 2020 at 3:05 PM LIU Zhiwei > wrote: > > > > On 2020/8/6 14:09, Chih-Min Chao wrote: >> On Fri, Jul 24, 2020 at 2:06 PM LIU Zhiwei > > wrote: >> >> >> >> On 2020/7/24 11:55, Richard Henderson wrote: >> > On 7/23/20 7:35 PM, LIU Zhiwei wrote: >> >> >> >> On 2020/7/24 8:28, Richard Henderson wrote: >> >>> Make sure that all results from single-precision scalar >> helpers >> >>> are properly nan-boxed to 64-bits. >> >>> >> >>> Signed-off-by: Richard Henderson >> > > >> >>> --- >> >>>    target/riscv/internals.h  |  5 +++++ >> >>>    target/riscv/fpu_helper.c | 42 >> +++++++++++++++++++++------------------ >> >>>    2 files changed, 28 insertions(+), 19 deletions(-) >> >>> >> >>> diff --git a/target/riscv/internals.h >> b/target/riscv/internals.h >> >>> index 37d33820ad..9f4ba7d617 100644 >> >>> --- a/target/riscv/internals.h >> >>> +++ b/target/riscv/internals.h >> >>> @@ -38,4 +38,9 @@ target_ulong fclass_d(uint64_t frs1); >> >>>    #define SEW32 2 >> >>>    #define SEW64 3 >> >>>    +static inline uint64_t nanbox_s(float32 f) >> >>> +{ >> >>> +    return f | MAKE_64BIT_MASK(32, 32); >> >>> +} >> >>> + >> >> If define it here,  we can also define a more general  >> function with flen. >> >> >> >> +static inline uint64_t nanbox_s(float32 f, uint32_t flen) >> >> +{ >> >> +    return f | MAKE_64BIT_MASK(flen, 64 - flen); >> >> +} >> >> + >> >> >> >> So we can reuse it in fp16 or bf16 scalar instruction and >> in vector instructions. >> > While we could do that, we will not encounter all possible >> lengths.  In the >> > cover letter, I mentioned defining a second function, >> > >> > static inline uint64_t nanbox_h(float16 f) >> > { >> >     return f | MAKE_64BIT_MASK(16, 48); >> > } >> > >> > Having two separate functions will, I believe, be easier to >> use in practice. >> > >> Get  it. Thanks. >> >> Zhiwei >> > >> > r~ >> >> >> >> That is what has been implemented in spike.  It fills up the >> Nan-Box when value is stored back internal structure and >> unbox the value with difference floating type >> (half/single/double/quad). > Hi Chih-Min, > > Has half-precision been a part of RVV? Or do you know the ISA > abbreviation of half-precision? > > Thanks very much. > > Best Regards, > Zhiwei >> >> By the way,  I prefer to keeping the suffix to tell >> different floating type rather than pass arbitrary >> since each floating type belong to each extension. >> >> Reviewed-by: Chih-Min Chao > > > > > Hi  ZhiWei, > > It is still under branch > https://github.com/riscv/riscv-isa-manual/tree/zfh and I am not sure > about the working group progress. > I have an implementation based on this draft and will send it as RFC > patch next week. Hi Chih-Min, Thanks for your information. As Krste said once,  as we don't have RV16, FP16 separated won't make sense.  Obviously, it has changed.:-P I also have implemented a version of FP16 ,“obvious set including existing FP instructions with format field set to "half" (fmt=10)“ If you want to send the patch, I will not send it again.:-) Zhiwei > > Thanks > Chih-Min --------------C4674CC0C5E7928B9A8680B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2020/8/6 16:42, Chih-Min Chao wrote:



On Thu, Aug 6, 2020 at 3:05 PM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:


On 2020/8/6 14:09, Chih-Min Chao wrote:
On Fri, Jul 24, 2020 at 2:06 PM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:


On 2020/7/24 11:55, Richard Henderson wrote:
> On 7/23/20 7:35 PM, LIU Zhiwei wrote:
>>
>> On 2020/7/24 8:28, Richard Henderson wrote:
>>> Make sure that all results from single-precision scalar helpers
>>> are properly nan-boxed to 64-bits.
>>>
>>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>>> ---
>>>    target/riscv/internals.h  |  5 +++++
>>>    target/riscv/fpu_helper.c | 42 +++++++++++++++++++++------------------
>>>    2 files changed, 28 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/target/riscv/internals.h b/target/riscv/internals.h
>>> index 37d33820ad..9f4ba7d617 100644
>>> --- a/target/riscv/internals.h
>>> +++ b/target/riscv/internals.h
>>> @@ -38,4 +38,9 @@ target_ulong fclass_d(uint64_t frs1);
>>>    #define SEW32 2
>>>    #define SEW64 3
>>>    +static inline uint64_t nanbox_s(float32 f)
>>> +{
>>> +    return f | MAKE_64BIT_MASK(32, 32);
>>> +}
>>> +
>> If define it here,  we can also define a more general  function with flen.
>>
>> +static inline uint64_t nanbox_s(float32 f, uint32_t flen)
>> +{
>> +    return f | MAKE_64BIT_MASK(flen, 64 - flen);
>> +}
>> +
>>
>> So we can reuse it in fp16 or bf16 scalar instruction and in vector instructions.
> While we could do that, we will not encounter all possible lengths.  In the
> cover letter, I mentioned defining a second function,
>
> static inline uint64_t nanbox_h(float16 f)
> {
>     return f | MAKE_64BIT_MASK(16, 48);
> }
>
> Having two separate functions will, I believe, be easier to use in practice.
>
Get  it. Thanks.

Zhiwei
>
> r~



That is what has been implemented in spike.  It fills up the Nan-Box when value is stored back internal structure and 
unbox the value with difference floating type (half/single/double/quad).
Hi Chih-Min,

Has half-precision been a part of RVV? Or do you know the ISA abbreviation of half-precision?

Thanks very much.

Best Regards,
Zhiwei

By the way,  I prefer to keeping the suffix to tell different floating type rather than pass arbitrary 
since each floating type belong to each extension.

Reviewed-by: Chih-Min Chao <chihmin.chao@sifive.com>

Hi  ZhiWei,

It is still under branch https://github.com/riscv/riscv-isa-manual/tree/zfh and I am not sure about the working group progress.
I have an implementation based on this draft and will send it as RFC patch next week.
Hi Chih-Min,

Thanks for your information.

As Krste said once,  as we don't have RV16, FP16 separated won't make sense.  Obviously, it has changed.:-P

I also have implemented a version of FP16 ,“obvious set including existing FP instructions with format field set to "half" (fmt=10)“

If you want to send the patch, I will not send it again.:-)


Zhiwei

Thanks
Chih-Min

--------------C4674CC0C5E7928B9A8680B7-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1k3cjU-00005h-6w for mharc-qemu-riscv@gnu.org; Thu, 06 Aug 2020 06:02:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57540) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k3cjR-00005O-OE; Thu, 06 Aug 2020 06:02:41 -0400 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:60679) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k3cjM-0001wd-Sc; Thu, 06 Aug 2020 06:02:41 -0400 X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06887019|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.0302796-0.00234627-0.967374; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16368; MF=zhiwei_liu@c-sky.com; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.IDMK18c_1596708147; Received: from 30.225.208.44(mailfrom:zhiwei_liu@c-sky.com fp:SMTPD_---.IDMK18c_1596708147) by smtp.aliyun-inc.com(10.147.42.197); Thu, 06 Aug 2020 18:02:28 +0800 Subject: Re: [PATCH v2 1/7] target/riscv: Generate nanboxed results from fp helpers To: Chih-Min Chao Cc: Richard Henderson , "qemu-devel@nongnu.org Developers" , Frank Chang , Alistair Francis , "open list:RISC-V" References: <20200724002807.441147-1-richard.henderson@linaro.org> <20200724002807.441147-2-richard.henderson@linaro.org> <1aa6cb56-2f41-45c1-2d32-ec8b3b10780b@c-sky.com> <9e10c17c-7a9e-5f7f-b1e3-c195d4e30b32@linaro.org> <4183e2c5-9a9b-2416-301d-95e62ac53a6c@c-sky.com> From: LIU Zhiwei Message-ID: <0631dbf2-9373-8ec6-f20b-1d5d137a7028@c-sky.com> Date: Thu, 6 Aug 2020 18:02:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C4674CC0C5E7928B9A8680B7" Content-Language: en-US Received-SPF: none client-ip=121.197.200.217; envelope-from=zhiwei_liu@c-sky.com; helo=smtp2200-217.mail.aliyun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/06 06:02:29 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-riscv@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 10:02:42 -0000 This is a multi-part message in MIME format. --------------C4674CC0C5E7928B9A8680B7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2020/8/6 16:42, Chih-Min Chao wrote: > > > > On Thu, Aug 6, 2020 at 3:05 PM LIU Zhiwei > wrote: > > > > On 2020/8/6 14:09, Chih-Min Chao wrote: >> On Fri, Jul 24, 2020 at 2:06 PM LIU Zhiwei > > wrote: >> >> >> >> On 2020/7/24 11:55, Richard Henderson wrote: >> > On 7/23/20 7:35 PM, LIU Zhiwei wrote: >> >> >> >> On 2020/7/24 8:28, Richard Henderson wrote: >> >>> Make sure that all results from single-precision scalar >> helpers >> >>> are properly nan-boxed to 64-bits. >> >>> >> >>> Signed-off-by: Richard Henderson >> > > >> >>> --- >> >>>    target/riscv/internals.h  |  5 +++++ >> >>>    target/riscv/fpu_helper.c | 42 >> +++++++++++++++++++++------------------ >> >>>    2 files changed, 28 insertions(+), 19 deletions(-) >> >>> >> >>> diff --git a/target/riscv/internals.h >> b/target/riscv/internals.h >> >>> index 37d33820ad..9f4ba7d617 100644 >> >>> --- a/target/riscv/internals.h >> >>> +++ b/target/riscv/internals.h >> >>> @@ -38,4 +38,9 @@ target_ulong fclass_d(uint64_t frs1); >> >>>    #define SEW32 2 >> >>>    #define SEW64 3 >> >>>    +static inline uint64_t nanbox_s(float32 f) >> >>> +{ >> >>> +    return f | MAKE_64BIT_MASK(32, 32); >> >>> +} >> >>> + >> >> If define it here,  we can also define a more general  >> function with flen. >> >> >> >> +static inline uint64_t nanbox_s(float32 f, uint32_t flen) >> >> +{ >> >> +    return f | MAKE_64BIT_MASK(flen, 64 - flen); >> >> +} >> >> + >> >> >> >> So we can reuse it in fp16 or bf16 scalar instruction and >> in vector instructions. >> > While we could do that, we will not encounter all possible >> lengths.  In the >> > cover letter, I mentioned defining a second function, >> > >> > static inline uint64_t nanbox_h(float16 f) >> > { >> >     return f | MAKE_64BIT_MASK(16, 48); >> > } >> > >> > Having two separate functions will, I believe, be easier to >> use in practice. >> > >> Get  it. Thanks. >> >> Zhiwei >> > >> > r~ >> >> >> >> That is what has been implemented in spike.  It fills up the >> Nan-Box when value is stored back internal structure and >> unbox the value with difference floating type >> (half/single/double/quad). > Hi Chih-Min, > > Has half-precision been a part of RVV? Or do you know the ISA > abbreviation of half-precision? > > Thanks very much. > > Best Regards, > Zhiwei >> >> By the way,  I prefer to keeping the suffix to tell >> different floating type rather than pass arbitrary >> since each floating type belong to each extension. >> >> Reviewed-by: Chih-Min Chao > > > > > Hi  ZhiWei, > > It is still under branch > https://github.com/riscv/riscv-isa-manual/tree/zfh and I am not sure > about the working group progress. > I have an implementation based on this draft and will send it as RFC > patch next week. Hi Chih-Min, Thanks for your information. As Krste said once,  as we don't have RV16, FP16 separated won't make sense.  Obviously, it has changed.:-P I also have implemented a version of FP16 ,“obvious set including existing FP instructions with format field set to "half" (fmt=10)“ If you want to send the patch, I will not send it again.:-) Zhiwei > > Thanks > Chih-Min --------------C4674CC0C5E7928B9A8680B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2020/8/6 16:42, Chih-Min Chao wrote:



On Thu, Aug 6, 2020 at 3:05 PM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:


On 2020/8/6 14:09, Chih-Min Chao wrote:
On Fri, Jul 24, 2020 at 2:06 PM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:


On 2020/7/24 11:55, Richard Henderson wrote:
> On 7/23/20 7:35 PM, LIU Zhiwei wrote:
>>
>> On 2020/7/24 8:28, Richard Henderson wrote:
>>> Make sure that all results from single-precision scalar helpers
>>> are properly nan-boxed to 64-bits.
>>>
>>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>>> ---
>>>    target/riscv/internals.h  |  5 +++++
>>>    target/riscv/fpu_helper.c | 42 +++++++++++++++++++++------------------
>>>    2 files changed, 28 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/target/riscv/internals.h b/target/riscv/internals.h
>>> index 37d33820ad..9f4ba7d617 100644
>>> --- a/target/riscv/internals.h
>>> +++ b/target/riscv/internals.h
>>> @@ -38,4 +38,9 @@ target_ulong fclass_d(uint64_t frs1);
>>>    #define SEW32 2
>>>    #define SEW64 3
>>>    +static inline uint64_t nanbox_s(float32 f)
>>> +{
>>> +    return f | MAKE_64BIT_MASK(32, 32);
>>> +}
>>> +
>> If define it here,  we can also define a more general  function with flen.
>>
>> +static inline uint64_t nanbox_s(float32 f, uint32_t flen)
>> +{
>> +    return f | MAKE_64BIT_MASK(flen, 64 - flen);
>> +}
>> +
>>
>> So we can reuse it in fp16 or bf16 scalar instruction and in vector instructions.
> While we could do that, we will not encounter all possible lengths.  In the
> cover letter, I mentioned defining a second function,
>
> static inline uint64_t nanbox_h(float16 f)
> {
>     return f | MAKE_64BIT_MASK(16, 48);
> }
>
> Having two separate functions will, I believe, be easier to use in practice.
>
Get  it. Thanks.

Zhiwei
>
> r~



That is what has been implemented in spike.  It fills up the Nan-Box when value is stored back internal structure and 
unbox the value with difference floating type (half/single/double/quad).
Hi Chih-Min,

Has half-precision been a part of RVV? Or do you know the ISA abbreviation of half-precision?

Thanks very much.

Best Regards,
Zhiwei

By the way,  I prefer to keeping the suffix to tell different floating type rather than pass arbitrary 
since each floating type belong to each extension.

Reviewed-by: Chih-Min Chao <chihmin.chao@sifive.com>

Hi  ZhiWei,

It is still under branch https://github.com/riscv/riscv-isa-manual/tree/zfh and I am not sure about the working group progress.
I have an implementation based on this draft and will send it as RFC patch next week.
Hi Chih-Min,

Thanks for your information.

As Krste said once,  as we don't have RV16, FP16 separated won't make sense.  Obviously, it has changed.:-P

I also have implemented a version of FP16 ,“obvious set including existing FP instructions with format field set to "half" (fmt=10)“

If you want to send the patch, I will not send it again.:-)


Zhiwei

Thanks
Chih-Min

--------------C4674CC0C5E7928B9A8680B7--