On Thu, Oct 8, 2026 at 8:36 PM Trevor Gross <[email protected]> wrote:
>
> 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.
I am not sure why this is a problem at all. When do you need to use
_Float16 without sse?
Or better this is an optional part of C23/C++23 in the first place so
it should not make a difference either way.
If this is for some other language besides C/C++, then why is this not
an optional part of the language like it is for C/C++?
Thanks,
Andrea
>
> 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
