[cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V

[Kito Cheng via cfe-dev]

Hi Sjoerd:
Thanks your reply, and apologize that I didn't tell the full story behind
this RFC:

- Ideally the `short float` is one of candidates of half precision types,
but it seems far from
  the way to standardize for including that in C or C++ std, so we didn’t
go this way.

- There is reason why we don't using _Float16 as RISC-V's proposal
  - _Float16 is belong with ISO/IEC TS 18661-3, which might included in
C2X, but
    not belong any C++ std yet, and the spec also didn't mention anything
about C++ part,
    however ISO/IEC TS 18661-3 also contain other interchange types and
extended types
    like _Float32_t, _Float32x_t, _Float64_t, _Float64x_t...and there is NO
C++ document for
    mangling rule of those types, so we would like to prevent to made this
global
    change in GCC side.
  - Default promotion rule is also one of our concerns, _Float16_t won't be
promoted to double,
    which is inconvenient for users, esp. for printf.

- The reason why we choose `__fp16` as the type name:
  - One major reason is __fp16 is widely used in this world rather than
_Float16.

-  Why do we decide to have different behavior?
  - We would like to default fully utilized hardware capability - if there
is half-precision
    then use it as possible.
  - We found some interesting things on __fp16 code gen behavior - native
half-precision
    instruction still might be generated when optimization is enabled, so
why not
    generated by default?
     * Code gen for __fp16 fadd16 (__fp16 a, __fp16 b) { return a + b; }
https://godbolt.org/z/3dasK9


Thanks.

On Fri, Mar 5, 2021 at 8:04 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote:

> And to add one more thought to this, I am actually working on deprecating
> __fp16 because there should be no good use case for it anymore with
> _Float16. This means that we will deprecate the type in the ACLE, it should
> give a warning when it is used, and eventually we would like to remove it
> in favour of _Float16. It also means that GCC would have to support
> _Float16. Deprecating __fp16 is work in progress but just wanted to
> illustrate the direction of travel.
>
> Cheers,
> Sjoerd.
> ------------------------------
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Sjoerd
> Meijer via cfe-dev <cfe-dev at lists.llvm.org>
> *Sent:* 05 March 2021 11:53
> *To:* Evandro Menezes <evandro.menezes at sifive.com>; Craig Topper <
> craig.topper at sifive.com>; Yi-Hsiu Hsu <yihsiu.hsu at sifive.com>; Kai Wang <
> kai.wang at sifive.com>; Zakk Chen <zakk.chen at sifive.com>;
> cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>; Kito Cheng <
> kito.cheng at sifive.com>
> *Subject:* Re: [cfe-dev] [RFC] Having different behavior for __fp16 on
> RISC-V
>
> Sorry, I noticed the patch first and left a comment there.
> But repeating what I wrote there: you're redefining an existing type to
> behave as another type, but only for some targets. I think this is
> problematic and not going to help anyone. Your motivation is that the type
> you would like to use is not supported by GCC, but that seems like the
> proper fix to me.
>
> Cheers,
> Sjoerd.
> ------------------------------
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Kito Cheng
> via cfe-dev <cfe-dev at lists.llvm.org>
> *Sent:* 05 March 2021 08:31
> *To:* Evandro Menezes <evandro.menezes at sifive.com>; Craig Topper <
> craig.topper at sifive.com>; Yi-Hsiu Hsu <yihsiu.hsu at sifive.com>; Kai Wang <
> kai.wang at sifive.com>; Zakk Chen <zakk.chen at sifive.com>;
> cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
> *Subject:* [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V
>
> RISC-V has a draft extension for half-precision proposed last year[1],
>
> so we think adding a new type for that would be great to make this
> easier to use that extension.
>
> We found there is _Float16 and __fp16 types are supported on GCC and
> Clang, but _Float16 has C++ supporting issues on GCC site, so we think
> support both types is a reasonable choice to us.
>
> However we would like have slight different behavior for __fp16 other
> than ACLE: The evaluation format of __fp16 set same as _Float16,
> which means no promotion are performed if there is no hardware
> half-precision
> supported.
>
> The only concern to us is it's defined differnt with clang's document,
> so we would put this RFC patch here, to make sure it's OK for make
> __fp16 has differnt behavior between differnt targets.
>
> This patch contains document change only, implementation would be in
> other patches.
>
> [1] https://github.com/riscv/riscv-isa-manual/pull/496
> [2] https://github.com/riscv/riscv-elf-psabi-doc/pull/172
>
>
> Corresponding phabricator entry for this RFC:
>
> https://reviews.llvm.org/D98012
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210308/afc61f9e/attachment.html>