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

[Kito Cheng via cfe-dev]

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/20210309/8e66609d/attachment.html>