On Wed, Nov 05, 2025 at 04:59:12PM +0000, Joseph Myers wrote: > On Wed, 5 Nov 2025, Michael Meissner wrote: > > > On Wed, Nov 05, 2025 at 10:02:05AM +0100, Jakub Jelinek wrote: > > > On Wed, Nov 05, 2025 at 03:53:15AM -0500, Michael Meissner wrote: > > > > This patch adds the necessary support in libgcc to allow using the > > > > machine > > > > independent 16-bit floating point support. > > > > > > No exports from libgcc_s.so.1? Is that because it is an experimental > > > feature so far, so you only want it in libgcc.a and not in libgcc.so? > > > > Good point. It is a work in progress. However, we probably need to > > make sure the calling sequence is what we want before putting it into a > > shared library. > > The ABI for the new types (including types such as _Complex _Float16) > definitely needs to be documented somewhere (for the various ABIs > supported by the back end, both 32-bit and 64-bit) so that all > implementations supporting those ABIs have a common reference for what > argument passing and return for _Float16, _Complex _Float16 and the other > types should look like.
Agreed, and that is why I think _Float16 and __bfloat16 should be labeled as experimental in GCC 16, with warnings when the types are passed or returned. Hopefully this will be official in GCC 17. There are essentially 4 options: 1: Pass and return 16-bit floating point values in memory format in the vector registers. This is what happens currently. And on the x86, this is what is done also. 2: Pass and return the 16-bit floating point vales in GPR registers instead of vector registers. The advantage of this option is it allows old C code that presumably used unsigned short as a fill-in for the 16-bit floating point types. But C++ doesn't really allow programs to lie like this. 3: Pretend it is 1989 and the original C standard is in place. In this system, we would convert the 16-bit floating point to 'double'. But with C++ and newer C standards, we require prototypes, and we no longer have the requirement that smaller floating point is converted to double. More practically, this is impossible to do without changing the machine independent code. Yes the code has an option to pass a value as a larger type, but it only works for integers. If you try to do it on floating point types, it just uses a SUBREG to get access to the bottom 16-bits. It maybe using the promotion macros work on floating point in some method, but I couldn't find the support to do it. Also for __bfloat16 on a power10, conversion between __bfloat16 and float/double takes 3 instructions that are serially dependant on each other to do the conversion (_Float16 takes a single instruction to do the conversion each way). I also suspect we would have to have a way to deal with the libgcc functions that don't do the extension. 4: Pass and return the 16-bit floating point values by reference. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: [email protected]
