[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