Hello everyone,
(Coordination, not GCC-specific)
We've been working for a while to make binary16 floats (_Float16) at
least somewhat usable on most architectures. The last snag is baseline
32-bit x86: the ABI specifies that _Float16 is returned in xmm0, but
that is not available if building without SSE.
This isn't too much of an obstacle in top-level code because you can do
something like return via *_Float16 or as a `short`. However, part of
the goal is to support operations, which is not trivially possible
because the i386 libcalls use the SSE ABI.
To support this situation and possibly others, I'm proposing a naming
convention for routines that pass floats as integers:
{base name}_soft{float ident} # for soft float routines
{base_name}_soft # for libm routines
A suffix like _softhf indicates that hf (f16) is passed via the
same-size integer ABI (short/u16). When a signature has multiple float
types, only the specified type is affected. So for the i386 case, the
runtime library would provide the following:
* __extendhfsf2(), f16->f32 (existing)
* __truncsfhf2(), f32->f16 (existing)
* __truncsfhf2_softhf(), f32->u16 (new)
Possibly also:
* Any others like __addhf3_softhf() (u16->u16) if needed
* sqrtf16_soft(), absf16_soft(), etc. (u16->u16). Not technically part
of libgcc, but often must be distributed for __builtin_sqrtf16().
A compiler can then use the standard __extendhfsf2(), __truncsfhf2(),
and sqrtf16() if SSE is available in the function or globally,
__truncsfhf2_softhf() and sqrtf16_soft() otherwise.
__extendhfsf2_softhf() isn't needed on i386 because only return ABI
requires SSE (but could be included for symmetry).
My original thought is that this pattern could extend to other
platforms, such as __addkf3_softkf() on PPC because _Float128 currently
requires VSX. However, it sounds like there is a possibility of
weakening the requirement to only Altivec so perhaps this won't be
needed.
Note that I don't actually expect GCC to make use of these because of an
aversion to ABI extensions, which is completely reasonable. However,
libgcc effectively owns the naming conventions that are used by most
other runtime libraries, so I'd like feedback that these names and plans
are reasonable enough as a form of coordination. (I.e. if GCC/libgcc did
ever want to support _Float16 ops on baseline i386, it would to know it
could follow the same conventions.) Copied the libgcc and soft-fp
maintainer for that reason.
So, any thoughts?
See also the LLVM issue at [1] where I initially brought this up, and a
few alternatives are discussed.
Kind regards,
Trevor
P.s. some ABI context at [2].
[1]: https://github.com/llvm/llvm-project/issues/112885
[2]:
https://inbox.sourceware.org/libc-alpha/[email protected]/T/#u
