2024-08-07 23:15 Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
>On 8/7/24 8:55 AM, Jakub Jelinek wrote:
>> 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?
>I'd tend to take a wait and see approach, meaning start when them as
>target builtins and promote them to generic builtins if we see other
>targets implementing a richer set of bf16 operations.
>
>> 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
>I have no idea on either of these questions.
>
>jeff
Thank you very much for the in-depth discussion between Jakub Jelinek and jeff.
My knowledge is narrow, and I am not familiar with architectures other than
RISCV.
At the same time, my understanding of libraries such as libc and libm is also
shallow.
I spent some time sorting out my thoughts, which resulted in slow email
replies. I am very sorry.
1 BF16 is a 16 bit floating-point data type that differs only in encoding from
FP16, but is otherwise the same.
2 BF16 can be used by any architecture, just like FP16.
3 libgcc provides interface functions related to floating-point types, such as
__mulsc3/__divsc3.
4 There is test case:
----------------------------------------------------------------------------------------
typedef _Complex float __cbf16 __attribute__((__mode__(__BC__)));
__cbf16 cbf16;
__cbf16 cbf16_1;
__cbf16 cbf16_2;
__cbf16 cbf16_mul_cbf16() { cbf16 = cbf16_1 * cbf16_2; }
__cbf16 cbf16_div_cbf16() { cbf16 = cbf16_1 / cbf16_2; }
----------------------------------------------------------------------------------------
4.1 Riscv architecture, -march=rv64imafdcv_zvfh -mabi=lp64d -O2. After
compilation, the resulting assembly will include:
----------------------------------------------------------------------------------------
call __mulbc3
call __divbc3
----------------------------------------------------------------------------------------
Due to the absence of the __mulbc3/__divbc3 interface in libgcc, this can
result in link errors.
4.2 Riscv architecture, -march=rv64imafdcv -mabi=lp64d -O2 After compilation,
the resulting assembly will include:
----------------------------------------------------------------------------------------
call __mulsc3
call __divsc3
----------------------------------------------------------------------------------------
Due to the presence of the __mulsc3/__divsc3 interface in libgcc, it can be
linked normally.
4.3 x86_64 architecture, the results obtained after testing are the same as the
Riscv architecture in 4.2, that is:
----------------------------------------------------------------------------------------
a) bf16 -> fp32
b) calls the corresponding complex interfaces __mulsc3/__divsc3
----------------------------------------------------------------------------------------
At the beginning, I had planned to only add the __mulbc3/__divbc3 interface in
libgcc.
After exploration, it was found that libgcc already has a complete
infrastructure, and adding
only the __mulbc3/__divbc3 interfaces would cause a lot of trouble.
In this context, it was decided to add a new data type BF16 to the
infrastructure of libgcc, similar to FP16.
Perhaps I can get some suggestions to complete the addition of
__mulbc3/__divbc3 and eliminate errors when linking.
Thanks
Xiao Zeng
