On Wed, Aug 07, 2024 at 08:46:11AM -0600, Jeff Law wrote:
>
>
> On 8/7/24 1:16 AM, Jakub Jelinek wrote:
>
> >
> > This looks all wrong to me.
> >
> > On all the other targets that already do support __bf16 type it is a storage
> > only type, so all arithmetics on it is expected to be done on float, not in
> > __bf16.
> RISC-V has (via extensions) degrees of arithmetic/conversion support, so for
> example it can do a multiply-add of bf16 operands widening to float.
Even the __builtin_*f16 _Float16 builtins are mostly unused (at least on
other targets), but there those functions are at least part of C23, even
when they are really not implemented yet in libm (at least talking about
glibc, but I doubt other C libraries are any further than that).
For __bf16, the only standard required stuff is in C++23 and the provided
builtins are whatever was necessary for that.
I understand RISC-V has via extensions more full _Float16 and __bf16
support, but if it needs further builtins, the questions are:
1) should they be enabled on all arches or just on those that need them?
2) is there plan to add libm support for __bf16, even when it is
non-standard in C (especially if we don't know if C2y or newer will or won't
add support for it and if it will use the chosen suffixes or some others)?
3) is there plan to add variants for C++23 <cmath> and <complex> etc.
to handle _Float16 and __bf16 differently? Currently those types are just
handled by doing as much as possible on float, using its builtins
Jakub
