在 2026-7-21 08:06, Trevor Gross 写道:
Coming here via the corresponding LLVM updates. I've done a lot of
digging on this topic and it seems like the general consensus is that
the ABI after this change is likely preferable to using a SSE register.
I had a similar patch ready at one point but decided not to send it
because of how I weighed the breakage (I am glad somebody else did).

I don't think the commit message is especially accurate, though, taking
some inspiration from LH's note at [1]. It says "following the MS x64
ABI" but there is no ABI for `__int128`. At best, we're reading between
the lines trying to figure out a reasonable extension ABI, and arguably
there is no bug in the first place because there is nothing to match.

`__int128` should be categorized as a user-defined type in Microsoft doc, like `long double` which is also returned in memory instead of ST(0).


Could either of you confirm what happens with this patch when `-mno-sse`
is passed? Currently it looks like a 2-register return [2], it would be
good if that's changed/tested here as well. (Note also that, as far as I
know, tests are completely broken on Windows hosts [3].)

In GCC 16:

   float
   returns_float(float f)
     {
       return f;
       // mov    eax, ecx
       // ret
     }

   double
   returns_double(double f)
     {
       return f;
       // mov    rax, rcx
       // ret
     }

   long double
   returns_long_double(long double f)
     {
       return f;
       // fld    TBYTE PTR [rdx]
       // mov    rax, rcx
       // fstp   TBYTE PTR [rcx]
       // ret
     }

   __int128
   returns_int128(__int128 x)
     {
       return x;
       // mov    rax, QWORD PTR [rcx]
       // mov    rdx, QWORD PTR [rcx + 0x8]
       // ret
     }

Summary: `float` and `double` are passed and returned in integer registers; `long double` is passed and returned in memory; `__int128` is passed in memory, but returned in RDX:RAX.

I think it is not correct to return `__int128` in RDX:RAX; it should always be 
returned in memory.



--
Best regards,
LIU Hao

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to