search for: x86_fastcall

...X, RetNode.getOperand (1)); SDOperand OpsTailCall [] = {Chain,DAG.getRegister(X86::ECX, getPointerTy())), RetNode.getOperand(2)}; RetNode = DCI.DAG.getNode(X86ISD::TAILCALL, TCVTs, OpsTailCall, 3); the downside here is that ECX is no longer free for passing function arguments. (i am using the x86_fastcall semantics at the moment with first two arguments stored in ecx,edx) does that sound sane? yes i will try against the trunk soon when i am in a masochistic deathly mood ;). maybe tonight. and sorry if i am bothering you with questions whose answer should be obvious. i am really a total newbi...

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

...obbered register available. This is used by trampolines, so if it's also used by JIT, which is almost surely the case, that will cause trouble. Even worse, it looks like the JIT is wrong even without trampolines, because for the C and X86_StdCall conventions it is ECX that is spare, while for X86_FastCall and Fast it is EAX. Yet the JIT always uses the same hardwired code, and does not adjust according to the calling convention. So presumably it is broken for one of these sets of calling conventions. Hopefully Anton can comment on this. > I tried telling lli to compile the entire program >...

...d some - sorry. > 3. > enum NameDecorationStyle { > None, > StdCall, > - FastCall > + FastCall, > + FastCC // the normal fastcc calling convention > }; > > Why is FastCC necessary? Can't you just use FastCall? FastCall is used to indicate a function has x86_FastCall semantics if i am not mistaken. I needed to differentiate between a normal fastcc and the x86_fastcall semantics in an older version of my code. I no longer depend on that so it can be removed as you suggest. sorry for the code corpse :) > 4. > def X86tailcall: SDNode<"X86ISD::T...

...hough. Also, we need to fold the subl into > addl if possible. I think you misunderstood me. I have not added code to insert this subl it is done already by the backend (before my changes) with certain calling conventions (callee pops arguments). There used to be already calling conventions e.g. x86_fastcall that would have 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. > > > > > > &g...

...ill be trying then is to emit a copytoreg from the virtual > register holding the > function pointer to ecx before the tailcall node. This seems to be the right way to do the things. > the downside here is that ECX is no longer free for passing function > arguments. (i am using the x86_fastcall semantics at the moment with > first two arguments stored in ecx,edx) This is the most problematic stuff here. Some notes: 1. You cannot emit a tail call to something returning a struct. 2. It can be tricky to emit a call to function having arguments in registers (emitting something target-dep...

Hi, We're using LLVM MCJIT on X86 platform. When calling Function::setCallingConv(CallingConv::X86_StdCall) the jitted code indeed conforms __stdcall convention (instead of default __cdecl). However applying Function::setCallingConv(CallingConv::X86_FastCall) seem does not have proper effect; jitted code is still __stdcall. Is it a bug, or am I missing something? Regards, Mikhail

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

...bl >> into >> addl if possible. > I think you misunderstood me. I have not added code to insert this > subl it is done already by the backend (before my changes) with > certain calling conventions (callee pops arguments). There used to be > already calling conventions e.g. x86_fastcall that would have 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. S...

...)); > SDOperand OpsTailCall [] = {Chain,DAG.getRegister(X86::ECX, > getPointerTy())), RetNode.getOperand(2)}; > RetNode = DCI.DAG.getNode(X86ISD::TAILCALL, TCVTs, OpsTailCall, 3); > > the downside here is that ECX is no longer free for passing function > arguments. (i am using the x86_fastcall semantics at the moment with > first > two arguments stored in ecx,edx) > > does that sound sane? > > yes i will try against the trunk soon when i am in a masochistic > deathly mood ;). maybe tonight. > and sorry if i am bothering you with questions whose answer should be &g...

Hola LLVMers, I'm working on engaging SSE via the LLVM vector ops on x86. I had some questions a while back that you all helped out on, but I'm seeing similar issues and was hoping you'd have some ideas. Below is the dump of the LLVM IR of a program which is designed to take a vector stored in a float*, build an LLVM vector from it, copy it to another vector, and then take it

On Sep 24, 2007, at 2:25 AM, Arnold Schwaighofer wrote: > > On 24 Sep 2007, at 09:18, Evan Cheng wrote: >> +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- >> output-file - | grep asm-printer | grep 9 >> +; change preceeding line form ... | grep 8 to ..| grep 9 since >> +; with new fastcc has std call semantics causing a stack adjustment >>

On 24 Sep 2007, at 09:18, Evan Cheng wrote: > +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- > output-file - | grep asm-printer | grep 9 > +; change preceeding line form ... | grep 8 to ..| grep 9 since > +; with new fastcc has std call semantics causing a stack adjustment > +; after the function call > > Not sure if I understand this. Can you illustrate