<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/10/2017 09:01 AM, Martin J.
O'Riordan wrote:<br>
</div>
<blockquote cite="mid:012e01d2c995$ede23260$c9a69720$@movidius.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 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-reply;
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;}
.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="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">Yes, I see how this
would be an issue if it is necessary to keep the
storage-only versus native types separate.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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();’.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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’).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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></p>
</div>
</blockquote>
<br>
Why? That should only be true if they have different semantics.<br>
<br>
-Hal<br>
<br>
<blockquote cite="mid:012e01d2c995$ede23260$c9a69720$@movidius.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"> MartinO<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></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 class="moz-txt-link-freetext" 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 class="moz-txt-link-rfc2396E" href="mailto:martin.oriordan@movidius.com"><martin.oriordan@movidius.com></a>; 'Hal Finkel'
<a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov"><hfinkel@anl.gov></a><br>
<b>Cc:</b> 'clang developer list'
<a class="moz-txt-link-rfc2396E" href="mailto:cfe-dev@lists.llvm.org"><cfe-dev@lists.llvm.org></a><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 class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">Hi
Hal, Martin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">Thanks
for the feedback.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB">Sjoerd.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-GB"><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"> 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<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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++.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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’).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">This solution has
worked very well over the past few years and is symmetric
with the other floating-point data types.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext">I’d love to see this
adopted as a formal type in a future version of ISO C and
ISO C++.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"> MartinO<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Book
Antiqua",serif;color:windowtext"><o:p> </o:p></span></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<o:p></o:p></span></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;font-family:"Times New
Roman",serif;mso-fareast-language:EN-IE"><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><span
style="font-size:10.0pt;font-family:"Courier
New";mso-fareast-language:EN-IE"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;color:windowtext;mso-fareast-language:EN-IE"
lang="EN-GB">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. <o:p></o:p></span></p>
</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>