<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hello Kito,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Let me also first backup a little bit by saying that we want the same thing: a half-type that maps efficiently to modern hardware. But by definition, __fp16 isn't that type.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
There are different alternatives here: try changing the semantics of an existing type, or adoption of a proper half type. <span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background: var(--white);">Your
proposal is problematic on different levels: i) changing the behaviour of an existing type, and ii) only do that for some targets. Your arguments that __fp16 is widely used and is thus convenient is problematic for i) because of the change in behaviour/expectations,
and ii) a type that behaves differently on different targets will be a source of confusion and non-portability. Thus, I don't see how your narrow proposal to change the type for only some targets is going to be more acceptable than e.g. changing it for all
targets. </span><span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background: var(--white);">We actually have discussed changing the semantics of __16 recently:</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<a href="https://lists.llvm.org/pipermail/cfe-dev/2020-December/067343.html" id="LPlnk144542">https://lists.llvm.org/pipermail/cfe-dev/2020-December/067343.html</a><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
There you'll see some pros/cons of doing this. But changing semantics is always going to have cons that will be awkward and there isn't going to be a really solution. That's why we are now taking the approach to deprecate __fp16.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To briefly comment on some your remarks:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<ul>
<li><span>You argue that there is a "standardisation gap" for _Float16, but that's why it is interesting that you end up advocating for __fp16, for which that gap is even bigger as it is a non-standard type.</span></li><li><span>In Clang, _Float16 is defined in both C and C++ mode for the targets that support this type.</span></li><li><span>C++ mangling is defined for _Float16. It isn't indeed for the other interchange types. But I don't see that as a fundamental problem.</span></li><li><span><span style="caret-color:rgb(0, 0, 0);text-align:start;background-color:rgb(255, 255, 255);display:inline !important">I don't think your codegen example is representative: this is 1 addition that indeed avoids the up and down conversions. And while
for some cases optimisations are possible, if you start looking at some bigger code examples that becomes more challenging, if possible at all in all cases, and it is all work and thing we can or should avoid.</span><br>
</span></li></ul>
<div>The way forward is a native half type, which is _Float16. And what we need to work on is support for it in GCC, which has to happen sooner or later I guess. And yes, there might also be some more standardisation/implementation work to do for _Float16.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Sjoerd.</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Kito Cheng <kito.cheng@sifive.com><br>
<b>Sent:</b> 08 March 2021 02:37<br>
<b>To:</b> Sjoerd Meijer <Sjoerd.Meijer@arm.com><br>
<b>Cc:</b> Evandro Menezes <evandro.menezes@sifive.com>; Craig Topper <craig.topper@sifive.com>; Yi-Hsiu Hsu <yihsiu.hsu@sifive.com>; Kai Wang <kai.wang@sifive.com>; Zakk Chen <zakk.chen@sifive.com>; cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Sjoerd:<br>
Thanks your reply, and apologize that I didn't tell the full story behind this RFC:<br>
<br>
- Ideally the `short float` is one of candidates of half precision types, but it seems far from<br>
the way to standardize for including that in C or C++ std, so we didn’t go this way.<br>
<br>
- There is reason why we don't using _Float16 as RISC-V's proposal<br>
- _Float16 is belong with ISO/IEC TS 18661-3, which might included in C2X, but<br>
not belong any C++ std yet, and the spec also didn't mention anything about C++ part,<br>
however ISO/IEC TS 18661-3 also contain other interchange types and extended types<br>
like _Float32_t, _Float32x_t, _Float64_t, _Float64x_t...and there is NO C++ document for<br>
mangling rule of those types, so we would like to prevent to made this global<br>
change in GCC side.<br>
- Default promotion rule is also one of our concerns, _Float16_t won't be promoted to double,<br>
which is inconvenient for users, esp. for printf.<br>
<br>
- The reason why we choose `__fp16` as the type name:<br>
- One major reason is __fp16 is widely used in this world rather than _Float16.<br>
<br>
- Why do we decide to have different behavior?<br>
- We would like to default fully utilized hardware capability - if there is half-precision<br>
then use it as possible.<br>
- We found some interesting things on __fp16 code gen behavior - native half-precision<br>
instruction still might be generated when optimization is enabled, so why not
<div> generated by default?<br>
* Code gen for __fp16 fadd16 (__fp16 a, __fp16 b) { return a + b; } <a href="https://godbolt.org/z/3dasK9">https://godbolt.org/z/3dasK9</a><br>
<br>
<br>
Thanks.<br class="x_gmail-Apple-interchange-newline">
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Fri, Mar 5, 2021 at 8:04 PM Sjoerd Meijer <<a href="mailto:Sjoerd.Meijer@arm.com">Sjoerd.Meijer@arm.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
And to add one more thought to this, I am actually working on deprecating __fp16 because there should be no good use case for it anymore with _Float16. This means that we will deprecate the type in the ACLE, it should give a warning when it is used, and eventually
we would like to remove it in favour of _Float16. It also means that GCC would have to support _Float16. Deprecating __fp16 is work in progress but just wanted to illustrate the direction of travel.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Cheers,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Sjoerd.<br>
</div>
<div id="x_gmail-m_5210996219289994847appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_gmail-m_5210996219289994847divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>>
on behalf of Sjoerd Meijer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Sent:</b> 05 March 2021 11:53<br>
<b>To:</b> Evandro Menezes <<a href="mailto:evandro.menezes@sifive.com" target="_blank">evandro.menezes@sifive.com</a>>; Craig Topper <<a href="mailto:craig.topper@sifive.com" target="_blank">craig.topper@sifive.com</a>>; Yi-Hsiu Hsu <<a href="mailto:yihsiu.hsu@sifive.com" target="_blank">yihsiu.hsu@sifive.com</a>>;
Kai Wang <<a href="mailto:kai.wang@sifive.com" target="_blank">kai.wang@sifive.com</a>>; Zakk Chen <<a href="mailto:zakk.chen@sifive.com" target="_blank">zakk.chen@sifive.com</a>>;
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; Kito Cheng <<a href="mailto:kito.cheng@sifive.com" target="_blank">kito.cheng@sifive.com</a>><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Sorry, I noticed the patch first and left a comment there.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
But repeating what I wrote there: you're redefining an existing type to behave as another type, but only for some targets. I think this is problematic and not going to help anyone. Your motivation is that the type you would like to use is not supported by GCC,
but that seems like the proper fix to me. <br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Cheers,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Sjoerd.<br>
</div>
<div id="x_gmail-m_5210996219289994847x_appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_gmail-m_5210996219289994847x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>>
on behalf of Kito Cheng via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Sent:</b> 05 March 2021 08:31<br>
<b>To:</b> Evandro Menezes <<a href="mailto:evandro.menezes@sifive.com" target="_blank">evandro.menezes@sifive.com</a>>; Craig Topper <<a href="mailto:craig.topper@sifive.com" target="_blank">craig.topper@sifive.com</a>>; Yi-Hsiu Hsu <<a href="mailto:yihsiu.hsu@sifive.com" target="_blank">yihsiu.hsu@sifive.com</a>>;
Kai Wang <<a href="mailto:kai.wang@sifive.com" target="_blank">kai.wang@sifive.com</a>>; Zakk Chen <<a href="mailto:zakk.chen@sifive.com" target="_blank">zakk.chen@sifive.com</a>>;
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><span style="color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">RISC-V has a draft extension for half-precision proposed last year[1],</span><br>
</div>
<div>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
so we think adding a new type for that would be great to make this<br>
easier to use that extension.</p>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
We found there is <tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere; margin-top:0px">_Float16</tt> and <tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere">__fp16</tt> types
are supported on GCC and<br>
Clang, but <tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere">_Float16</tt> has C++ supporting issues on GCC site, so we think<br>
support both types is a reasonable choice to us.</p>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
However we would like have slight different behavior for <tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere; margin-top:0px">__fp16</tt> other<br>
than ACLE: The evaluation format of <tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere">__fp16</tt> set same as <tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere">_Float16</tt>,<br>
which means no promotion are performed if there is no hardware half-precision<br>
supported.</p>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
The only concern to us is it's defined differnt with clang's document,<br style="margin-top:0px">
so we would put this RFC patch here, to make sure it's OK for make<br>
<tt style="background:rgba(71,87,120,0.1); padding:1px 4px; border-radius:3px; white-space:pre-wrap; line-break:anywhere">__fp16</tt> has differnt behavior between differnt targets.</p>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
This patch contains document change only, implementation would be in<br style="margin-top:0px">
other patches.</p>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
[1] <a href="https://github.com/riscv/riscv-isa-manual/pull/496" rel="noreferrer" target="_blank" style="text-decoration-line:none; color:rgb(19,108,178); margin-top:0px">https://github.com/riscv/riscv-isa-manual/pull/496</a><br>
[2] <a href="https://github.com/riscv/riscv-elf-psabi-doc/pull/172" rel="noreferrer" target="_blank" style="text-decoration-line:none; color:rgb(19,108,178)">https://github.com/riscv/riscv-elf-psabi-doc/pull/172</a></p>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
<br>
</p>
<div>Corresponding phabricator entry for this RFC:</div>
<p style="margin:0px 0px 12px; padding:0px; border:0px; color:rgb(0,0,0); font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif; font-size:13px">
<a href="https://reviews.llvm.org/D98012" target="_blank">https://reviews.llvm.org/D98012</a><br>
</p>
<div></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>