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

Thu Mar 11 08:19:42 PST 2021

In fact there is kind of awkward story behind this, we chose __fp16 rather than _Float16, major reason is GCC supporting, and also we saw ARM/AArch64 deprecated that for a while, but _Float16 problem still there in GCC, so we decide to using __fp16 rather than _Float16.
I am not really following this.
And we also considering the compatible issue there, I mean the compatibility of ACLE's __fp16, __fp16 isn't a language extension for GCC, it's a target specific type for ARM/AArch64, so if we don't define that as a formal extension types, then we have broken support/compiler compatibility issue on this due to GCC didn't support __fp16 as language extension.
And am not entirely sure about this.

I don't think I have changed my mind on this topic, and I don't know what else/more I can add to what I have already mentioned.
I won't repeat my arguments, but the bottom line is that we want to deprecate __fp16, while you like to rebrand it to a native half-precision type, and I don't see how this goes together very well. I also remain unconvinced about the arguments against _Float16, which I think is the solution.

I don't know what your options are now. Maybe someone else can weigh in and shine a light on this, perhaps I am missing something. I don't know if you can go ahead and make these changes if you get an LGTM from someone else, but I hope the community sees the problem of the same type behaving different on different targets.

Cheers,
Sjoerd.

________________________________
From: Kito Cheng <kito.cheng at sifive.com>
Sent: 09 March 2021 15:56
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 for your reply again :)

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.

Yeah, I know the cc1 option, it can be passed by -Xclang -fnative-half-type, and we can hide this into the clang driver, but it kind of semantic change of __fp16 for RISC-V target, we would like to add a non-cc1 option -m or -f option there rather than a cc1 option here.

And I can fully understand breaking ACLE is not reasonable, I think if some guy wants to break that, the guys must come from ARM not a RISC-V guys :P

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.

In fact there is kind of awkward story behind this, we chose __fp16 rather than _Float16, major reason is GCC supporting, and also we saw ARM/AArch64 deprecated that for a while, but _Float16 problem still there in GCC, so we decide to using __fp16 rather than _Float16.

And we also considering the compatible issue there, I mean the compatibility of ACLE's __fp16, __fp16 isn't a language extension for GCC, it's a target specific type for ARM/AArch64, so if we don't define that as a formal extension types, then we have broken support/compiler compatibility issue on this due to GCC didn't support __fp16 as language extension.

RISC-V has no backward compatibility issue there so we are trying to take both compatibility and hw supporting utilization from __fp16.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210311/f52ba18b/attachment-0001.html>