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

[Sjoerd Meijer via cfe-dev]

Sorry, I noticed the patch first and left a comment there.
But repeating what I wrote there: you're redefining an existing type to behave as another type, but only for some targets. I think this is problematic and not going to help anyone. Your motivation is that the type you would like to use is not supported by GCC, but that seems like the proper fix to me.

Cheers,
Sjoerd.
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Kito Cheng via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 05 March 2021 08:31
To: 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: [cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V

RISC-V has a draft extension for half-precision proposed last year[1],

so we think adding a new type for that would be great to make this
easier to use that extension.

We found there is _Float16 and __fp16 types are supported on GCC and
Clang, but _Float16 has C++ supporting issues on GCC site, so we think
support both types is a reasonable choice to us.

However we would like have slight different behavior for __fp16 other
than ACLE: The evaluation format of __fp16 set same as _Float16,
which means no promotion are performed if there is no hardware half-precision
supported.

The only concern to us is it's defined differnt with clang's document,
so we would put this RFC patch here, to make sure it's OK for make
__fp16 has differnt behavior between differnt targets.

This patch contains document change only, implementation would be in
other patches.

[1] https://github.com/riscv/riscv-isa-manual/pull/496
[2] https://github.com/riscv/riscv-elf-psabi-doc/pull/172


Corresponding phabricator entry for this RFC:

https://reviews.llvm.org/D98012
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210305/456efbbd/attachment-0001.html>