similar to: [LLVMdev] Handling SRet on Windows x86

On Tue, Oct 2, 2012 at 7:03 PM, Anton Korobeynikov <asl at math.spbu.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

On Tue, Oct 2, 2012 at 11:02 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >> On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> [+cfe-dev as this does seem like both LLVM+Clang issue] >>> [Sorry for an incomplete e-mail context,

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

On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > [+cfe-dev as this does seem like both LLVM+Clang issue] > [Sorry for an incomplete e-mail context, please see > http://llvm.org/PR13676#c6 if you're interested] > > I've read these bugs and now I'm even more confused than I was before :) > > What do you think about the

[+cfe-dev as this does seem like both LLVM+Clang issue] [Sorry for an incomplete e-mail context, please see http://llvm.org/PR13676#c6 if you're interested] I've read these bugs and now I'm even more confused than I was before :) What do you think about the following approach: a) I'll create test cases for the major issues I've observed so far These test cases will check

On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >> [+cfe-dev as this does seem like both LLVM+Clang issue] >> [Sorry for an incomplete e-mail context, please see >> http://llvm.org/PR13676#c6 if you're interested] >> >> I've read

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

On Fri, Aug 12, 2011 at 1:11 AM, Damien Gleizes <gleizesd at gmail.com> wrote: > > Hi all, > > I am trying to generate LLVM IR that calls an external C++ function > returning a structure by copy: > vec3 vec3::Cross(const vec3& iV) const; > > Here is the LLVM IR that I am generating for win32 ABI, which says that the > first parameter should be a pointer to the

Anton, [+Eric, Nick, the e-mail thread context has been broken a few times, so you should probably look at the llvmdev archives. It all starts here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] So I've decided to make a new attempt to fix this issue. We've discussed my patches with Eric and came up with the following idea: a) IsTargetWindows should be true for

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

Hi all, I am trying to generate LLVM IR that calls an external C++ function returning a structure by copy: vec3 vec3::Cross(const vec3& iV) const; Here is the LLVM IR that I am generating for win32 ABI, which says that the first parameter should be a pointer to the return value: %vec3 = type <{ float, float, float }> define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint

On 20/02/2008, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Feb 2008, Raja Mukherji wrote: > > Hi all, > > I was wondering what the best way of adding a custom calling convention in llvm? > > It is quite easy to add custom calling conventions. Check out how the > various x86 fastcall, stdcall, etc things are handled. Am I correct in thinking that it's

2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: > Anton, > > [+Eric, Nick, > the e-mail thread context has been broken a few times, so you should > probably look at the llvmdev archives. > It all starts here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053961.html ] > > So I've decided to make a new attempt to fix this issue. > >

On Dec 28, 2010, at 4:02 PM, drizzle drizzle wrote: > Hi > Is there a way to enforce a different alignment on vales on stack > as compared to other basic types. Particularly, i would like > characters to be stored at 2 byte boundary. > Check out examples in the lib/Target/* directories. For instance in X86CallingConv.td, we have things like this: def CC_X86_64_C :

Thanks for the answer.. A followup question - Is this already taken into consideration when generating address calculation offset etc or would this need to be specially taken care? I am assuming all load/stores also would need to be custom lowered. thanks dz On Wed, Dec 29, 2010 at 5:45 AM, Bill Wendling <wendling at apple.com> wrote: > On Dec 28, 2010, at 4:02 PM, drizzle drizzle

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

Hi Is there a way to enforce a different alignment on vales on stack as compared to other basic types. Particularly, i would like characters to be stored at 2 byte boundary. thanks dz

On 31.5.2014 2:04, Pasi Parviainen wrote: > On 28.5.2014 2:57, Sanjoy Das wrote: >> Hi llvmdev, >> >> I'm trying to figure how llvm remembers stack slots allotted to callee >> saved registers on x86. In particular, llvm pushes registers in >> decreasing order of FrameIdxs [1], so the offsets they get (as >> returned by MFI->getObjectOffset) don't

Hi Evan, I incoporated the changes you request but to the following i have got a question: > Also, moving the option > there will allow us to change fastcc ABI (callee popping arguments) > only when this option is on. See Chris' email: I am not to sure on that. because that would make modules compiled with the flag on incompatible with ones compiled without the flag off as