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

Sjoerd Meijer via cfe-dev cfe-dev at lists.llvm.org
Mon Mar 8 01:36:44 PST 2021 

Hello Kito,

Let me also first backup a little bit by saying that we want the same thing: a half-type that maps efficiently to modern hardware. But by definition, __fp16 isn't that type.

There are different alternatives here: try changing the semantics of an existing type, or adoption of a proper half type. Your proposal is problematic on different levels: i) changing the behaviour of an existing type, and ii) only do that for some targets. Your arguments that __fp16 is widely used and is thus convenient is problematic for i) because of the change in behaviour/expectations, and ii) a type that behaves differently on different targets will be a source of confusion and non-portability. Thus, I don't see how your narrow proposal to change the type for only some targets is going to be more acceptable than e.g. changing it for all targets.  We actually have discussed changing the semantics of __16 recently:
https://lists.llvm.org/pipermail/cfe-dev/2020-December/067343.html

There you'll see some pros/cons of doing this. But changing semantics is always going to have cons that will be awkward and there isn't going to be a really solution. That's why we are now taking the approach to deprecate __fp16.

To briefly comment on some your remarks:

  *   You argue that there is a "standardisation gap" for _Float16, but that's why it is interesting that you end up advocating for __fp16, for which that gap is even bigger as it is a non-standard type.
  *   In Clang, _Float16 is defined in both C and C++ mode for the targets that support this type.
  *   C++ mangling is defined for _Float16. It isn't indeed for the other interchange types. But I don't see that as a fundamental problem.
  *   I don't think your codegen example is representative: this is 1 addition that indeed avoids the up and down conversions. And while for some cases optimisations are possible, if you start looking at some bigger code examples that becomes more challenging, if possible at all in all cases, and it is all work and thing we can or should avoid.

The way forward is a native half type, which is _Float16. And what we need to work on is support for it in GCC, which has to happen sooner or later I guess. And yes, there might also be some more standardisation/implementation work to do for _Float16.

Cheers,
Sjoerd.


________________________________
From: Kito Cheng <kito.cheng at sifive.com>
Sent: 08 March 2021 02:37
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: 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: Re: [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V

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<mailto: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<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 05 March 2021 11:53
To: Evandro Menezes <evandro.menezes at sifive.com<mailto:evandro.menezes at sifive.com>>; Craig Topper <craig.topper at sifive.com<mailto:craig.topper at sifive.com>>; Yi-Hsiu Hsu <yihsiu.hsu at sifive.com<mailto:yihsiu.hsu at sifive.com>>; Kai Wang <kai.wang at sifive.com<mailto:kai.wang at sifive.com>>; Zakk Chen <zakk.chen at sifive.com<mailto:zakk.chen at sifive.com>>; cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>; Kito Cheng <kito.cheng at sifive.com<mailto: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<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Kito Cheng via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 05 March 2021 08:31
To: Evandro Menezes <evandro.menezes at sifive.com<mailto:evandro.menezes at sifive.com>>; Craig Topper <craig.topper at sifive.com<mailto:craig.topper at sifive.com>>; Yi-Hsiu Hsu <yihsiu.hsu at sifive.com<mailto:yihsiu.hsu at sifive.com>>; Kai Wang <kai.wang at sifive.com<mailto:kai.wang at sifive.com>>; Zakk Chen <zakk.chen at sifive.com<mailto:zakk.chen at sifive.com>>; cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <cfe-dev at lists.llvm.org<mailto: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/f32a7f54/attachment-0001.html>

More information about the cfe-dev mailing list