similar to: [LLVMdev] RFC: tailcall ppc32 patch

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

tailcall optimization stop working in jit (lli) in revision 45527. i guess this is because the jit is tailjmping to the wrong function address. the following change would reenable tailcallopt in jit. But i am pretty sure that this is not the correct fix (since i don't really understand what is going on :). maybe evan can comment on this? regards arnold Index:

Yes please. Evan On Oct 5, 2007, at 11:55 AM, Arnold Schwaighofer wrote: > > On 5 Oct 2007, at 20:47, Evan Cheng wrote: > >> >> On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: >> >>> >>>> We can set a policy of treating fastcc external functions >>>> as c functions. Then there is no chance of introducing ABI >>>>

Another round ;) Sadly not beer. tested against r42630 darwin-x86: SPASS llc-beta still fails thanks for the patience On 5 Oct 2007, at 20:58, Evan Cheng wrote: > Yes please. >> okay then i'll make tailcallopt switch stack adjusting behaviour? the patch for the test suite (when/if it's needed) would be something like: >>>>> --- Makefile.programs (revision

On 25 Dec 2007, at 03:29, Gordon Henriksen wrote: > Hi Jo, > > On 2007-12-24, at 14:43, Joachim Durchholz wrote: > >> I'm in a very preliminary phase of a language project which requires >> some specific optimizations to be reasonably efficient. >> >> LLVM already looks very good; I'd just like to know whether I can >> push these optimizations

In order to test the tail call optimization i created quite a few .ll files and added them to the SingleSource directory in the test-suite. For example llvm-test/SingleSource/Tailcall/tailcall1-2.ll. Since i don't want opt to inline the tailcalls away :) i changed the rules in the Makefile situated in the TailCall directory. I want to compare the output of a file compile with normal llc with

Hi Arnold, Thanks for the insights. My comments below: On Thu, Feb 14, 2013 at 5:30 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of

Happy 2011, everybody! It seems -tailcallopt prevents tailcall optimization when both caller and callee have ccc, even when it is optimized without an option -tailcallopt. Is it intended or misoptimized? In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization(): if (GuaranteedTailCallOpt) { if (IsTailCallConvention(CalleeCC) && CCMatch) return true;

For marking a call site as a tail call you have to call void setTailCall(bool isTC = true) on the CallInst. The calling convention of the function needs to be CallingConv::Fast (currently only fastcc calls are optimized) and the call has to be in tail position of course. To enable tail call optimization in an embedded vm i guess you would include llvm/Target/TargetOptions.h and set the static

On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: > >> We can set a policy of treating fastcc external functions >> as c functions. Then there is no chance of introducing ABI >> incompatibility. > this means limiting tail call opt to protected/invisible functions > within a module? > a little limiting i think. It makes sense to be extra careful at this point.

On Jan 1, 2011, at 4:20 PM, NAKAMURA Takumi wrote: > Happy 2011, everybody! > > It seems -tailcallopt prevents tailcall optimization when both caller > and callee have ccc, > even when it is optimized without an option -tailcallopt. Sorry, I don't understand your question. What do you mean by both caller and callee have ccc? Evan > Is it intended or misoptimized? >

When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of the stack. The caller cannot transitively know the tail callee's tailcallee's requirement. Also care must be taken to make sure the stack stays

On 5 Oct 2007, at 20:47, Evan Cheng wrote: > > On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: > >> >>> We can set a policy of treating fastcc external functions >>> as c functions. Then there is no chance of introducing ABI >>> incompatibility. >> this means limiting tail call opt to protected/invisible functions >> within a module?

Hi Albert, nice to see someone is using the tail call stuff. i am responsible for the mess (feature) ;). Tail call optimization currently (llvm 2.3) works (to varying degrees, see http://llvm.org/docs/CodeGenerator.html#tailcallopt) for x86(-64) and ppc32/64. x86 being more mature (testing) than ppc. ppc64 has received the least testing. regards

>> While investigating one of the existing tests >> (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some >> interesting code. The IR is very straightforward: >> >> define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 >> %a4) { >> entry: >> ret i32 %a3 >> } >> >> define fastcc i32 @tailcaller(i32

On 5 Oct 2007, at 19:41, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> 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.

On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote: > Hello Dale, > > this is an updated version of the tail call optimization patch for > powerpc. could you have a look at it? > > i added code to support ppc64 (untested, will try to get access to > ppc64 on a friend's machine). > incorporated evan's formatting suggestions. ;) > > will run another round

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > 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

On Thu, Feb 12, 2009 at 5:34 PM, Jeff Kuskin <jk500500 at yahoo.com> wrote: > Two related questions. > (2) Why does the x86-64 JIT backend generate a "ret $0x8" instruction > to return from a fastcc function that is (a) marked as fastcc > (CallingConv::Fast); but (b) takes no arguments and returns 'void'? fastcc generated code ends with this: > c20800

Tail calls through function pointers should work.If not please send a testcase. I just added the two examples from the bug (1392) that calls for true tail call support. They work on my machine (-tailcallopt needs to be enabled) ;) That would be commit 56127. regards On Thu, Sep 11, 2008 at 11:21 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Arnold implemented tail call. We