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

Tue Mar 9 05:42:55 PST 2021

Hi Kito,
So what about if add a new command-line option, I saw Richard Sandiford has mentioned this but seems no follow up discussion for this point.
Perhaps I shouldn't have mentioned this, but I believe this options is already there. 🙂I think with cc1 option -fnative-half-type you'll get the behaviour that you want. But having said this, my vote is against documenting and defining that this is how __fp16 works. This results in non-portable and ACLE breaking code.

And quoting from the original RFC, I want to reiterate that this looks to me like a very bad motivation to change __fp16 over here in Clang:
but_Float16has C++ supporting issues on GCC site
My alternative proposal is to fix this in GCC. This is something we want or need to fix anyway at some point, so I am guessing my Arm colleagues working on GCC would be happy to help here.

Cheers,
Sjoerd.
________________________________
From: Kito Cheng <kito.cheng at sifive.com>
Sent: 09 March 2021 09:08
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:

On Mon, Mar 8, 2021 at 5:37 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com<mailto:Sjoerd.Meijer at arm.com>> wrote:
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.

Yes, I believe we are on the same page for this.

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

Thanks for providing this link, it's a really great conversation there, one major reason I purpose for changing the behavior of some target (or more specific, RISC-V only at this moment) is because I know there is ACLE spec for ARM and AArch64, I think it's not reasonable to change the behavior of all other target especially for ARM/AArch64.

So what about if add a new command-line option, I saw Richard Sandiford has mentioned this but seems no follow up discussion for this point.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210309/ac55ae93/attachment-0001.html>