search for: cc_x86_32_c

...be exceptions from the general Win32 handling code. That is, b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI is used and false for Cygwin+MinGW. c) We should add CC_X86_Win32_C and CC_X86_Win32_ThisCall and use them only for MSVC 32-bit ABI. d) Cygwin and MinGW should use the CC_X86_32_C This way, Clang takes care of setting the SRet attribute wherever appropriate and LLVM takes care of putting such return values onto stack in the Win32/MSVC32 ABI. What do you think about such a proposal? One more data point: the ABI is wrong even in C! http://llvm.org/bugs/show_bug.cgi?id=15556...

...e is some code checking whether a TAIL CALL really is eligible for tail call optimization. I modified: LowerRET to create a TC_RETURN node. (used for adjusting stackpointer and jumping to function in epilogue, similar to EH_RETURN) There is a new calling convention: CC_X86_32_TailCall which is ~ CC_X86_32_C minus ECX. There are some modifications in X86InstrInfo.td There are new X86 DAG nodes: TRUETAILCALL TC_RETURN There is some voodoo in X86RegisterInfo.cpp to deal with the RETADDR problem described in X86ISelLowering.cpp comments. (callee has more args than caller -> there needs to be space...

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

> Ah, got it. > Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. No, we should not. It should be properly expanded in frontend. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...ented stacks. Are segmented stacks actually used with MSVC or is it just the conditions there should use isTargetMingw() && !is64Bit() instead? > c) We should add CC_X86_Win32_C and CC_X86_Win32_ThisCall and use them > only for MSVC 32-bit ABI. > d) Cygwin and MinGW should use the CC_X86_32_C > > This way, Clang takes care of setting the SRet attribute wherever appropriate > and LLVM takes care of putting such return values onto stack in the > Win32/MSVC32 ABI. > > What do you think about such a proposal? > > One more data point: the ABI is wrong even in C! >...

...ly is > eligible for tail call optimization. > > I modified: > LowerRET > to create a TC_RETURN node. (used for adjusting stackpointer and > jumping to function in epilogue, similar to EH_RETURN) > > There is a new calling convention: > CC_X86_32_TailCall > which is ~ CC_X86_32_C minus ECX. > > There are some modifications in > X86InstrInfo.td > > There are new X86 DAG nodes: > TRUETAILCALL > TC_RETURN > > > There is some voodoo in X86RegisterInfo.cpp to deal with the > RETADDR problem described in X86ISelLowering.cpp comments. > (callee...

...er a call is > eligible for tail call elimination and insert the current ISD::CALL > node. Okay > X86TargetLowering::LowerX86_32FastCCCallTo() will not have to > handle non-tail calls. > I will then add code to LowerCCCCallTo() to check whether to use the normal calling convention CC_X86_32_C (3 registers free for argument passing) or the tail call (fastcc) calling convention CC_X86_32_TailCall (2 register free). Expect to see a new patch after i have done the testing with the whole test suite. regards arnold