[cfe-commits] [PATCH] Supporting thiscall compatibility with MSVC

Eli Friedman eli.friedman at gmail.com
Wed Feb 15 19:48:16 PST 2012


On Wed, Feb 15, 2012 at 7:37 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Wed, Feb 15, 2012 at 8:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>
>> Index: lib/Target/X86/X86CallingConv.td
>> ===================================================================
>> --- lib/Target/X86/X86CallingConv.td    (revision 150629)
>> +++ lib/Target/X86/X86CallingConv.td    (working copy)
>> @@ -333,6 +333,9 @@
>>
>>   // The 'nest' parameter, if any, is passed in EAX.
>>   CCIfNest<CCAssignToReg<[EAX]>>,
>> +
>> +  // Do not pass the sret argument in ECX
>> +  CCIfSRet<CCDelegateTo<CC_X86_32_Common>>,
>>
>>   // The first integer argument is passed in ECX
>>   CCIfType<[i32], CCAssignToReg<[ECX]>>,
>>
>> You say "*all* byval struct returns for thiscall methods are passed
>> through the hidden pointer in EAX", but your patch puts the sret
>> argument on the stack, if I'm not mistaken...
>
> The caller allocates space on the stack and puts the pointer to it in
> EAX, the callee then uses that pointer to fill out the return value,
> and before returning it needs to ensure that EAX points to what the
> caller passed in.
>
> So should I be using CCPassIndirect<i32> instead to accomplish this?
> And what should I do about the "nest" parameter wanting to be in EAX?
> Should I move that to another reg instead?

You want "CCIfSRet<CCAssignToReg<[EAX]>>,", no?

I doubt anyone cares about the interaction between thiscall and nested
function, so I would say just don't worry about it.

-Eli




More information about the cfe-commits mailing list