[LLVMdev] Handling SRet on Windows x86
aaron at aaronballman.com
Tue Oct 2 08:26:07 PDT 2012
Something to keep in mind...when I was researching it, thiscall was a
bit odd (at least to me) in MSVC. It pushes the structure onto the
stack from the caller, but it returns the pointer to the structure in
EAX and cleans up the pushed stack. The caller then either reloads
the structure from its local stack, or it uses EAX to access it. The
latter is especially true if it involves a temp.
On Tue, Oct 2, 2012 at 10:34 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote:
> Hello Aaron, Anton, LLVM-dev,
> While working on http://llvm.org/PR13676#c6
> I found out that whenever I compile code with class methods returning
> structures it get generated incompatible with MSVC.
> Looking at lib/Target/X86/X86CallingConv.td, I found out that
> CC_X86_32_ThisCall maps SRet to EAX but in fact it should push
> the address of the return temp on stack.
> The following patch fixes the issue on Windows:
> Index: lib/Target/X86/X86CallingConv.td
> --- lib/Target/X86/X86CallingConv.td (revision 164763)
> +++ lib/Target/X86/X86CallingConv.td (working copy)
> @@ -335,7 +335,8 @@
> CCIfType<[i8, i16], CCPromoteToType<i32>>,
> // Pass sret arguments indirectly through EAX
> - CCIfSRet<CCAssignToReg<[EAX]>>,
> + CCIfSRet<CCAssignToStack<4, 4>>,
> // The first integer argument is passed in ECX
> CCIfType<[i32], CCAssignToReg<[ECX]>>,
> [hope this doesn't get wrapped in your email client]
> Unfortunately, this patch also changes how SRet/ThisCall behaves
> non-Windows systems too (right?).
> I'd like to ask for advice:
> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms?
> [I suppose no]
> b) Should I be altering CC_X86_32_ThisCall
> OR should I introduce CC_X86_Win32_ThisCall instead?
> [Answer not clear to me - is there any platform besides Windows
> that uses thiscall?]
> Probably I need to create CC_X86_Win32_ThisCall (and maybe
> CC_X86_Win32_C later) by copying CC_X86_32_ThisCall similar to how
> CC_X86_Win64_C is done - does that sound right?
> Hints and suggestions on fixing this are welcome!
> Timur Iskhodzhanov,
> Google Russia
More information about the llvm-dev