On Thu, Oct 8, 2026 at 8:41 PM Andrea Pinski
<[email protected]> wrote:
>
> 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++?
A couple extra points. Using Float inside the Linux kernel (even for
rust) is normally frowned upon. So I am not sure why you need a soft
fp for _Float16 at all.
I think the rust folks not allowing optional features is making it
harder to support normal code.
>
> 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
