<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 05/11/2017 06:22 AM, Sjoerd Meijer
wrote:<br>
</div>
<blockquote
cite="mid:AM5PR0801MB1843FA15C78F271AABC6FE14FCED0@AM5PR0801MB1843.eurprd08.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;
mso-fareast-language:EN-US;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;
mso-fareast-language:EN-IE;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;
mso-fareast-language:EN-US;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;
mso-fareast-language:EN-US;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;
mso-fareast-language:EN-US;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Book Antiqua","serif";
font-variant:normal !important;
color:windowtext;
text-transform:none;
font-weight:normal;
font-style:normal;
text-decoration:none none;
vertical-align:baseline;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Book Antiqua","serif";
font-variant:normal !important;
color:windowtext;
text-transform:none;
font-weight:normal;
font-style:normal;
text-decoration:none none;
vertical-align:baseline;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Hal,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">You mentioned
“I'd be in favor of changing the current semantics”. Just
checking: do you mean the semantics of __fp16?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Because that is
exactly what we are trying to avoid with introducing a new
true half type; changing semantics of fp16 would break
backward compatibility.</span></p>
</div>
</blockquote>
<br>
I don't mean changing the semantics of __fp16, the source-language
type. I mean changing the semantics of the IR-level half type. I
suspect we can do this along with an auto-upgrade feature that does
not break backwards compatibility (by inserting extend/truncate
around operations in old IR as I described to adjust for the
existing semantics as you described them).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:AM5PR0801MB1843FA15C78F271AABC6FE14FCED0@AM5PR0801MB1843.eurprd08.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">> By "when
required", do you mean when the result would<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">> be the
same as if the operation had been performed in single
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">> precision?
If so, then no, we need different semantics<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I think that is
indeed the case, but I am double checking that.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Sjoerd.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-GB"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-GB"
lang="EN-US"> Hal Finkel [<a class="moz-txt-link-freetext" href="mailto:hfinkel@anl.gov">mailto:hfinkel@anl.gov</a>] <br>
<b>Sent:</b> 10 May 2017 17:40<br>
<b>To:</b> Sjoerd Meijer; Martin J. O'Riordan<br>
<b>Cc:</b> 'clang developer list'; nd<br>
<b>Subject:</b> Re: [cfe-dev] [RFC] implementation of
_Float16<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 05/10/2017 11:15 AM, Sjoerd Meijer
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D">The thing
that confused me again is that for simple
expressions/examples like this:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">__fp16
MyAdd(__fp16 a, __fp16 b) {</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> return a +
b;</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">}</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">The IR does
not include promotions/truncations which you would expect
(because operations are done on floats):</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">define half
@MyAdd(half %a, half %b) local_unnamed_addr #0 {</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">entry:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> %0 = fadd
half %a, %b</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> ret half %0</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">}</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">But that is
only because there is this optimisation that does not
include them if it can prove that the result with/without
these converts is the same, so in other cases the
promotes/truncates are there as expected.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">This means
that Clang produces the necessary promotions when needed,
and that a new _Float16 type can also be mapped onto the
LLRM IR half type I think (no changes needed). Yes, then
the approach could indeed be to treat it as a native type,
and only promote operands to floats when required.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman","serif";mso-fareast-language:EN-GB"><br>
By "when required", do you mean when the result would be the
same as if the operation had been performed in single
precision? If so, then no, we need different semantics. That
having been said, I'd be in favor of changing the current
semantics to require explicit promotions/truncations, change
the existing optimization to elide them when they're
provably redundant (as we do with other such things), and
then only have a single, true, half-precision type. I
suspect that we'd need to figure out how to auto-upgrade,
but that seems doable.<br>
<br>
-Hal<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Cheers,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Sjoerd.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-GB"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-GB"
lang="EN-US"> Hal Finkel [<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov">mailto:hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> 10 May 2017 16:00<br>
<b>To:</b> Martin J. O'Riordan; Sjoerd Meijer<br>
<b>Cc:</b> 'clang developer list'<br>
<b>Subject:</b> Re: [cfe-dev] [RFC] implementation of
_Float16</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p> <o:p></o:p></p>
<div>
<p class="MsoNormal">On 05/10/2017 09:01 AM, Martin J.
O'Riordan wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt">Yes, I see
how this would be an issue if it is necessary to keep the
storage-only versus native types separate.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">At the
moment I have ‘short float’ internally associated with
OpenCL’s ‘half’ but I do not enable ‘half’ as a keyword.
Independently I have made ‘__fp16’ when used with our
target also be a synonym for ‘short float/half’ (simply to
avoid adding a new keyword). This in turn is bound to the
IEEE FP16 using ‘HalfFormat =
&llvm::APFloat::IEEEhalf();’.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">In our
case it is always a native type and never a storage only
type, so coupling ‘__fp16’ to ‘half’ made sense.
Certainly if the native versus storage-only variants were
distinct, then this association I have made would have to
be decoupled (not a big-deal).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Another
approach might be to always work with FP16 as-if native,
but to provide only Load/Store instructions in the
TableGen descriptions for FP16, and to adapt lowering to
always perform the arithmetic using FP32 if the selected
target does not support native FP16 - would that be
feasible in your case? In this way it is not really any
different to how targets that have no FPU can use an
alternative integer based implementation (with the help of
‘compiler-rt’).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I can
certainly see how something like ‘ADD’ of ‘f16’ could be
changed to use ‘Expand’ in lowering rather than ‘Legal’ as
a function of the selected target (or some other target
specific option) - we just marked it ‘Legal’ and provided
the corresponding instructions in TableGen with very
little custom lowering necessary. I have a mild concern
that LLVM would have to have an ‘f16’ which is native and
another kind-of ‘f16’ restricted to being only storage.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
Why? That should only be true if they have different
semantics.<br>
<br>
-Hal<br>
<br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">
MartinO</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="color:windowtext;mso-fareast-language:EN-IE"
lang="EN-US">From:</span></b><span
style="color:windowtext;mso-fareast-language:EN-IE"
lang="EN-US"> Sjoerd Meijer [<a moz-do-not-send="true"
href="mailto:Sjoerd.Meijer@arm.com">mailto:Sjoerd.Meijer@arm.com</a>]
<br>
<b>Sent:</b> 10 May 2017 14:19<br>
<b>To:</b> Martin J. O'Riordan <a
moz-do-not-send="true"
href="mailto:martin.oriordan@movidius.com"><martin.oriordan@movidius.com></a>;
'Hal Finkel'
<a moz-do-not-send="true" href="mailto:hfinkel@anl.gov"><hfinkel@anl.gov></a><br>
<b>Cc:</b> 'clang developer list' <a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"><cfe-dev@lists.llvm.org></a><br>
<b>Subject:</b> RE: [cfe-dev] [RFC] implementation of
_Float16</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi Hal, Martin,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for the
feedback.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Yes, the issue
indeed is that ‘__fp16’ is already used to implement a
storage-only type. And earlier I wrote that I don’t expect
LLVM IR changes, but now I am not so sure anymore if both
types map onto the same half LLVM IR type. With two half
precision types, __fp16 and _Float16, where one is a storage
only type and the other a native type, somehow the
distinction between these two must be made I think.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Cheers,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Sjoerd.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-GB"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-GB"
lang="EN-US"> Martin J. O'Riordan [<a
moz-do-not-send="true"
href="mailto:martin.oriordan@movidius.com">mailto:martin.oriordan@movidius.com</a>]
<br>
<b>Sent:</b> 10 May 2017 14:13<br>
<b>To:</b> 'Hal Finkel'; Sjoerd Meijer<br>
<b>Cc:</b> 'clang developer list'<br>
<b>Subject:</b> RE: [cfe-dev] [RFC] implementation of
_Float16</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Our
Out-of-Tree target implements fully native FP16 operations
based on ‘__fp16’ (scalar and SIMD vector), so is the issue
for ARM that ‘__fp16’ is already used to implement a
storage-only type and that another type is needed to
differentiate between a native and a storage-only type?
Once the ‘f16’ type appears in the IR (and the vector
variants) the code-generation is straightforward enough.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Certainly we
have had to make many changes to CLang and to LLVM to fully
implement this including suppression of implicit conversion
to ‘double’, but nothing scary or obscure. Many of these
changes are simply to enable something that is already
normal for OpenCL, but to do so for C and C++.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">More
controversially we also added a “synonym” for this using
‘short float’ rather than ‘_Float16’ (or OpenCL’s ‘half’),
and created a parallel set of the ISO C library functions
using ‘s’ to suffix the usual names (e.g. ‘tan’, ‘tanf’,
‘tanl’ plus ‘tans’). The ‘s’ suffix was unambiguous (though
we actually use the double-underscore prefix, e.g. ‘__tans’
to avoid conflict with the user’s names) and the type ‘short
float’ was available too without breaking anything.
Enabling the ‘h’ suffix for FP constants (again from OpenCL)
makes the whole fit smoothly with the normal FP types.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">However, for
variadic functions (such as ‘printf’) we do promote to
‘double’ because there are no formatting specifiers
available for ‘half’ any more than there is support for
‘float’ - it is also consistent with ‘va_arg’ usage for
‘char’ and ‘short’ as ‘int’. My feeling is that using
implementation defined types ‘float’, ‘double’ and ‘long
double’ can be extended to include ‘short float’ without
dictating that they have any particular bit-sizes (e.g. FP16
for ‘half’).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">This
solution has worked very well over the past few years and is
symmetric with the other floating-point data types.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">There are
some issues with C++ and overloading because ‘__fp16’ to
other FP types (and INT types) is not ranked in exactly the
same way as for example ‘float’ is to other FP types; but
this is really only because it is not a 1<sup>st</sup> class
citizen of the type-system and the rules would need to be
specified to make this valid. I have not tried to fix this
as it works reasonably well as it is, and it would really be
an issue for the C++ committee to decide if they ever choose
to adopt another FP data type. I did add it to the traits
in the C++ library though so that it is considered legal for
floating-point types.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I’d love to
see this adopted as a formal type in a future version of ISO
C and ISO C++.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">
MartinO</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="color:windowtext;mso-fareast-language:EN-IE"
lang="EN-US">From:</span></b><span
style="color:windowtext;mso-fareast-language:EN-IE"
lang="EN-US"> cfe-dev [<a moz-do-not-send="true"
href="mailto:cfe-dev-bounces@lists.llvm.org">mailto:cfe-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Hal Finkel via cfe-dev<br>
<b>Sent:</b> 10 May 2017 11:39<br>
<b>To:</b> Sjoerd Meijer <<a moz-do-not-send="true"
href="mailto:Sjoerd.Meijer@arm.com">Sjoerd.Meijer@arm.com</a>>;
<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] implementation of
_Float16</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On 05/10/2017 05:18 AM, Sjoerd Meijer via
cfe-dev wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">ARMv8.2-A introduces as an optional
extension half-precision data-processing instructions for
Advanced SIMD and floating-point in both AArch64 and AArch32
states [1], and we are looking into implementing
C/C++-language support for these new ARMv8.2-A
half-precision instructions.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">We would like to introduce a new Clang
type. The reason is that we e.g. cannot use type __fp16
(defined in the ARM C Language Extensions [2]) because it is
a storage type only. This means when using standard C
operators values of __fp16 type promote to float when used
in arithmetic operations, which we would like to avoid for
the ARMv8.2-A half-precision instructions. Please note that
the LLVM IR already has a half precision type, onto which
for example __fp16 is mapped, so there are no changes or
additions required for the LLVM IR.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">As a new Clang type we would like to
propose _Float16 as defined in a C11 extension, see [3].
Arithmetic is well defined, it is not only a storage type as
__fp16. Our question is whether a partial implementation,
just implementing this type and not claiming (full) C11
conformance is acceptable?<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
I would very much like to see fp16 as a first-class
floating-point type in Clang and LLVM (i.e. handling that is
not just a storage type). Doing this in Clang in a way that
is specified by C11 seems like the right approach. I don't
see why implementing this would be predicated on
implementing other parts of C11.<br>
<br>
-Hal</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">IMPORTANT
NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and
do not disclose the contents to any other person, use it for
any purpose, or store or copy the information in any medium.
Thank you.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
<br>
<br>
</span><o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman","serif";mso-fareast-language:EN-GB"><br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>