search for: cc_x86_win32_thiscall

...] 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...

...ru> wrote: > Hello Timur, > >> I'd like to ask for advice: >> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >> [I suppose no] > 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?] > no Can you please clarify which question you've answered here? Sorry for making the ambiguous questions in the first place :) > It seems for me that you're trying...

...OK to change the SRet/ThisCall behaviour on non-Windows platforms? >>>>>> [I suppose no] >>>>> 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?] >>>>> no >>>> Can you please clarify which question you've answered here? >>>> Sorry for making the ambi...

On Tue, Oct 2, 2012 at 8:44 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >>>> 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?] >>> no >> Can you please clarify which question you've answered here? > To both. You're assuming that Windows == MSVC. This is not true....

Hello Timur, > I'd like to ask for advice: > a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? > [I suppose no] 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?] no It seems for me that you're trying to solve the problem from the wrong end. As far as I remember, there is a difference - "simple" (probable POD-like stuff) are returned...

...ke to ask for advice: >>>> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >>>> [I suppose no] >>> 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?] >>> no >> Can you please clarify which question you've answered here? >> Sorry for making the ambiguous questions in the first place :) &g...

...;s Cygwin and MinGW (that are similar more similar to Itanium ABI than to MSVC ABI) that should 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 m...

...> >>> I'd like to ask for advice: >>> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >>> [I suppose no] >> 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?] >> no > Can you please clarify which question you've answered here? > Sorry for making the ambiguous questions in the first place :) > >> It seems...

...t;>>> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >>>>> [I suppose no] >>>> 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?] >>>> no >>> Can you please clarify which question you've answered here? >>> Sorry for making the ambiguous questions in t...

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

...here's already such a method but it is (mis?)used only in lib/Target/X86/X86FrameLowering.cpp for segmented 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 y...