<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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);">
In Arm we are considering/discussing changing the semantics of storage-only type</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
__fp16 and we are looking for feedback on this. The motivation is that in A-profile,
<div>architecture extension FP16 natively supports half-precision arithmetic. It is</div>
<div>also supported by SVE, and in M-profile MVE optionally supports it. </div>
<div><br>
</div>
<div>The problem is that float16_t is defined in the Arm C-Language Extensions</div>
<div>(ACLE) specification [1] as an alias for __fp16. Thus, using the float16_t /</div>
<div>__fp16 storage-only type which performs arithmetic in single-precision, we are</div>
<div>not taking advantage of the native half-precision FP16 instructions.</div>
<div><br>
</div>
<div>One obvious solution is to change the float16_t typedef in the ACLE from this:</div>
<div><br>
</div>
<div> typedef __fp16 float16_t;</div>
<div><br>
</div>
<div>to use _Float16 instead of __fp16, where _Float16 is the type with</div>
<div>half-precision arithmetic semantics. An alternative is to change the semantics</div>
<div>of __fp16, and both approaches have their pros and cons:</div>
<div><br>
</div>
<div>Changing the semantics of __fp16 (approach A):</div>
<div>- Pros:</div>
<div>-- There is no ABI break.</div>
<div>-- Code that uses __fp16 also benefits from the more optimal implementation.</div>
<div>- Cons: </div>
<div>-- No type would retain the old __fp16 semantics.</div>
<div>-- We'd need to change the compiler frontends (both Clang and GCC).</div>
<div>-- Existing code could rely on current __fp16 behaviour.</div>
<div><br>
</div>
<div>Keeping the semantics of __fp16 (approach B):</div>
<div>- Pros:</div>
<div>-- People who want the old behaviour can use __fp16 directly.</div>
<div>-- We only need to change a typedef in a header file.</div>
<div>- Cons: </div>
<div>-- Changing float16_t requires an ABI break.</div>
<div>-- Code that directly uses __fp16 would not benefit from the new float16_t optimisation.</div>
<div><br>
</div>
<div>Deciding for one of these approaches is difficult as people may get</div>
<div>happy/unhappy either way and it is difficult to quantify this, which is why we</div>
<div>welcome any feedback on this from e.g. users of __fp16. If for example the</div>
<div>opinion is that breaking the ABI is a last resort, then that would point into the</div>
<div>direction of Approach A and changing the semantics of __fp16.</div>
<div><br>
</div>
[1] <a href="https://developer.arm.com/documentation/101028/latest" id="LPlnk">https://developer.arm.com/documentation/101028/latest</a><br>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<br>
</div>
</body>
</html>