On Wed, Mar 4, 2026 at 6:33 AM Trevor Gross <[email protected]> wrote:
> Hello all, > > I am interested in revisiting the return ABI of _Float16 on i386. > Currently it is returned in xmm0, meaning SSE is required for the type. > This is rather inconvenient when _Float16 is otherwise quite well > supported. Compilers need to pick between hacking together a custom ABI > that works on the baseline, or passing the burden on to users to gate > everything. > > Is there any interest in adjusting the specification such that _Float16 > is returned in a GPR rather than SSE? > > This was brought up before in the thread at [1], with the concern about > efficient 16-bit moves between GPRs or memory and XMM. This doesn't seem > to be relevant, however, given there isn't any reason to have a _Float16 > in XMM unless F16C is available, implying SSE2 and SSE4.1 for PINSRW and > PEXTRW to/from memory (unless I am missing something?). > > A sample patch to the psABI is below. Needless to say there are > compatibility concerns that come from a change but given workarounds > already exist (e.g. in LLVM), it seems worth considering whether > something should be codefied to make this simpler for everyone. > Both F16C (announced 2009) and SSE (announced 1999) are widely available in practice. It's good that there's interest in supporting older CPUs, but I don't think it's unreasonable for the ABI to be... I can't even say "forward-looking", more like "not quite that backward-looking". Compiler flags that enable the type with an incompatible ABI seem like a fine solution for code that's actually unwilling to commit to a 25-year-old minimum hardware target; there's no problem as long as the code doesn't have a call that crosses an ABI boundary. John.
