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

Mon Mar 15 05:41:41 PDT 2021

Hi Craig and Kito,

Thanks for starting the GCC thread. I have added my thoughts there too. Looks like the GNU community is open about enabling _Float16, so I think that this is the approach that we should take.

Craig contacted me about different behaviour between GCC and Clang when FP16 isn't enabled, for example: https://godbolt.org/z/vx6rnG. My colleague reminded me that this is related to FLT_EVAL_METHOD. With FLT_EVAL_METHOD=0, smaller types and expressions are evaluated in single-precision without the need for intermediate rounding. So, GCC is right here, and Clang is wrong. With FP16 enabled, we see that GCC switches to FLT_EVAL_METHOD=16, where as in Clang we still use 0 which is wrong: https://godbolt.org/z/j3KhGa.

I wanted to raise a ticket for this, but noticed that you already did: https://bugs.llvm.org/show_bug.cgi?id=43475. I will add some information to that a bit later.

Cheers,
Sjoerd.

________________________________
From: Craig Topper <craig.topper at gmail.com>
Sent: 11 March 2021 22:06
To: James Y Knight <jyknight at google.com>
Cc: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; Yi-Hsiu Hsu <yihsiu.hsu at sifive.com>; Zakk Chen <zakk.chen at sifive.com>; cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>; Evandro Menezes <evandro.menezes at sifive.com>; Craig Topper <craig.topper at sifive.com>
Subject: Re: [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V

A thread has been started on the gcc mailing list. https://gcc.gnu.org/pipermail/gcc/2021-March/234962.html

~Craig

On Thu, Mar 11, 2021 at 10:43 AM James Y Knight via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

On Thu, Mar 11, 2021 at 11:20 AM Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
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.

I don't know why _Float16 isn't implemented by GCC in C++ mode, but I'd agree that using _Float16 for RISC-V, and adding support for _Float16 to GCC's C++ mode does seem like the better solution here, especially given that such support will also be needed for ARM.

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210315/9830ab33/attachment.html>