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

[Kito Cheng via cfe-dev]

Hi Sjoerd:


On Mon, Mar 8, 2021 at 5:37 PM Sjoerd Meijer <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/e5ad7d28/attachment.html>