[LLVMdev] Handling SRet on Windows x86

[Timur Iskhodzhanov]

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!

--
Thanks,
Timur Iskhodzhanov,
Google Russia