<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>Hi Sjoerd,</p>
    <p><br>
    </p>
    <p>our downstream target also supports the __fp16 type as a pure
      storage type. The hardware offers instructions to convert between
      half-precision and single-precision, but no arithmetic.</p>
    <p>Do you propose to eliminate the storage-only type altogether, or
      just renaming it (in your approach A)?</p>
    <p><br>
    </p>
    <p>Konstantin<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 08.12.2020 12:23, Sjoerd Meijer via
      cfe-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DB6PR0801MB19902B02EB75A05C9BB1405DFCCD0@DB6PR0801MB1990.eurprd08.prod.outlook.com">
      <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>
      <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" moz-do-not-send="true">https://developer.arm.com/documentation/101028/latest</a><br>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
  </body>
</html>