<div dir="ltr"><div dir="ltr">Hi Sjoerd:<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 5:37 PM Sjoerd Meijer <<a href="mailto:Sjoerd.Meijer@arm.com" target="_blank">Sjoerd.Meijer@arm.com</a>> wrote:<br></div><blockquote class="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)">
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></blockquote><div><br></div><div>Yes, I believe we are on the same page for this.</div><div><br></div><div> </div><blockquote class="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)">
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">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">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="m_7995761465860581877m_-5387145978463008404m_-4750494524860872023gmail-m_4750271967371424103LPlnk144542" target="_blank">https://lists.llvm.org/pipermail/cfe-dev/2020-December/067343.html</a></div></div></blockquote><div><br></div><div>Thanks for providing this link, it's a really great conversation there, one major reason I purpose for changing the behavior of some target (or more specific, RISC-V only at this moment) is because I know there is ACLE spec for ARM and AArch64, I think it's not reasonable to change the behavior of all other target especially for ARM/AArch64. </div><div><br></div><div>So what about if add a new command-line option, I saw Richard Sandiford has mentioned this but seems no follow up discussion for this point.</div><div><br></div><div> </div><blockquote class="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)"><span style="font-size:12pt">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.</span><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)">
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></ul></div></div></blockquote><blockquote class="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)"><ul><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="text-align:start;background-color:rgb(255,255,255);display:inline">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></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>
<div></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>

</blockquote></div></div>