search for: x86callingconv

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

...ose registers. And the reason > for this was the offset fixing logic within emitCalleeSavedFrameMoves, > which breaks when fixing offset for XMM registers. > > To fix this disparity, I concluded that it could be done by reversing > definition order of general purpose registers within X86CallingConv.td > for all calling conventions, since llvm prefers to use push/pop model > for storing GPR:s (for x86). With this change stack slots and registers > would have 1:1 mapping, without extra offset calculations and > emitCalleeSavedFrameMoves could be simplified by removing extra magic to...

...ler() { int x= call fastcc callee(); //!! caller pops the arguments => stack mismatch callee pops the arguments but caller also wants to pop the arguments of the stack Apparently i forgot to send the answer email to chris reponse. sorry for that. > >> Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately >> that's not controlled by options. Ok then. >> > > Sure it can be, you can set up custom predicates, for example the > X86CallingConv.td file has: > > class CCIfSubtarget<string F, CCAction A> > : CCIf<!strconcat("State.g...

...t; > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue emission :) > So: > > 1. Calling conventions > Partly tablegen / partly C++ code. Look for > CodeGen/SelectionDAG/CallingConvLower.cpp, > Target/X86/X86CallingConv.td and around. Usually this code is run > during different phases of sdag lowering. > > 2. Prologue / epilogue. > Pure C++ code. Look into CodeGen/PrologEpilogInserter.cpp (quite > obviously, right?) with bunch of target-specialized hooks, for > example, ones located in Target/X86...

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 directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

...rote: > > 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 the X86CallingConv.td file that needs to changed? I've had a look at it and I think I can figure out how to write the calling convention, but I'm a bit lost trying to integrate it into the rest of the code. In particular, how do I assign an integer for use in the setCallingConv(unsigned CC) method? > >...

...cause > the stack adjustment only fastcc was not one of them. Now that fastcc > can cause tail call optimization i had to change the convention from > caller pops arguments to callee pops arguments in order to allow tail > call optimization in a general way. Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately that's not controlled by options. Ok then. >> >>> >>> >>>> Index: include/llvm/Target/TargetLowering.h >>>> =================================================================== >>>> --- include/llvm/Target/T...

...See include/llvm/Target/ TargetOptions.h, lib/Target/TargetMachine.cpp Also, moving the option there will allow us to change fastcc ABI (callee popping arguments) only when this option is on. See Chris' email: > Sure it can be, you can set up custom predicates, for example the > X86CallingConv.td file has: > > class CCIfSubtarget<string F, CCAction A> > : CCIf<! strconcat("State.getTarget().getSubtarget<X86Subtarget>().", F), A>; > > It would be straight-forward to have a CCIf defined to check some command > line argument. +/// IsE...

...de > or TableGen generated ? > > If someone could point me in the right direction please. Calling convention is really-really far from prologue/epilogue emission :) So: 1. Calling conventions Partly tablegen / partly C++ code. Look for CodeGen/SelectionDAG/CallingConvLower.cpp, Target/X86/X86CallingConv.td and around. Usually this code is run during different phases of sdag lowering. 2. Prologue / epilogue. Pure C++ code. Look into CodeGen/PrologEpilogInserter.cpp (quite obviously, right?) with bunch of target-specialized hooks, for example, ones located in Target/X86/X86RegisterInfo.cpp. Informa...

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

...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 : CallingConv<[ ... // __m64 vectors get 8-byte stack slots that are 8-byte aligned. CCIfType<[x86mmx,v1i64], CCAssignToStack<8, 8>> } The second parameter to CCAssigneToStack is...

...> >> 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 : CallingConv<[ > ... >  // __m64 vectors get 8-byte stack slots that are 8-byte aligned. >  CCIfType<[x86mmx,v1i64], CCAssignToStack<8, 8>> > } > > The second parameter to CCAssigneToStack is the alignment for...

...> If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue > emission :) So: > > 1. Calling conventions > Partly tablegen / partly C++ code. Look for > CodeGen/SelectionDAG/CallingConvLower.cpp, > Target/X86/X86CallingConv.td and around. Usually this code is run > during different phases of sdag lowering. > > 2. Prologue / epilogue. > Pure C++ code. Look into CodeGen/PrologEpilogInserter.cpp (quite > obviously, right?) with bunch of target-specialized hooks, for > example, ones located in Target/X86...

How/where are function prologs and epilogs generated, is it bespoke C++ code or TableGen generated ? If someone could point me in the right direction please. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090409/fb3336e4/attachment.html>

...% of the > time with the current set of assumptions, > but I would rather determine it dynamically so that I can change my > assumptions and still get the right results. Why would you want to map arguments to registers based on names? Calling conventions are encoded in td files such X86CallingConv.td. Parameter registers etc. are determined from argument number / type, not names. Evan > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P...

...finitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to time. > If the answer is to add support for x64 windows calling conventions, > which parts of LLVM should I be looking at to understand what needs to > be done? The CC is described in the X86CallingConv.td file and also some other bits are expanded in the X86ISelLowering.cpp The changes needed for windows64 CC are pretty straightforward modification of the current x86-64 CC (I even can try to find my preliminary patch made this summer). However, there is one pretty ugly thing currently totally...

> > FastCC use to be caller pops arguments so there was no stack > > adjustment after the > > call to qux. Now FastCC has callee pops arguments on return semantics > > so the > > x86 backend inserts a stack adjustment after the call. > > > > _array: > > subl $12, %esp > > movss LCPI1_0, %xmm0 > > mulss

I am having trouble trying to figure out two pieces of information from attempting to map arguments to registers. How do I determine, based on the argument name, which register the value is supposed to be assigned to? I can hard-coded it currently and it will be correct 100% of the time with the current set of assumptions, but I would rather determine it dynamically so that I can change my

...> //!! caller pops the arguments => stack mismatch > > callee pops the arguments but caller also wants to pop the arguments > of the stack > > Apparently i forgot to send the answer email to chris reponse. sorry > for that. >> >>> Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately >>> that's not controlled by options. Ok then. >>> >> >> Sure it can be, you can set up custom predicates, for example the >> X86CallingConv.td file has: >> >> class CCIfSubtarget<string F, CCAction A> >> :...

...nto Visual Studio-generated code. For example, http://llvm.org/bugs/show_bug.cgi?id=5058 , http://llvm.org/bugs/show_bug.cgi?id=5064 . Not sure about the particular issue you're running into; looks like a bug at first glance. The file that mostly controls this sort of thing is lib/Target/X86/X86CallingConv.td . -Eli