similar to: [LLVMdev] Removing -tailcallopt?

Thanks for improving this! Since no good deed can go unpunished, could you also update the LangRef and codegen documents to describe the new state of the world? It might also be nice to mention there that tail calls can be needed for correctness in addition to performance and how users can guarantee that a call will be transformed, since both if us have forgotten recently. I can take a stab at the

Evan Cheng wrote: > As far as I can tell only PPC and X86 targets are supporting this option. Does anyone actually using it? I'd prefer to just remove it to clean up the implementation if no one has any objections. Don't know whether that is the same, but my Pure compiler sets llvm::PerformTailCallOpt. Pure needs TCO because it doesn't have any built-in looping constructs. In

I am somewhat surprised people are actually using TCO. I had to fixed a number of subtle bugs to get it working and even now I am not too happy with it. My focus was on finding non-ABI changing automatic tail call cases (aka gcc's sibcall). It's now done so I'll leave -tailcallopt alone for now. I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. Evan On Feb 5,

On Feb 5, 2010, at 9:03 PM, Jeffrey Yasskin wrote: > Thanks for improving this! Since no good deed can go unpunished, could > you also update the LangRef and codegen documents to describe the new > state of the world? It might also be nice to mention there that tail I plan to do this part before 2.7. > calls can be needed for correctness in addition to performance and how > users

Evan Cheng wrote: > I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. Jeffrey apparently fixed that now, I'm going to test against trunk asap. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: >> Does anyone actually using it? > > Yes, many LLVM-based projects rely upon TCO to work correctly. Ok, that's all I need to know. > >> I'd prefer to just remove it to clean up the implementation if no one has >> any objections. > > Are you

My tests show x86_64 -tailcallopt JIT working fine on Mac OS X. Evan On Feb 6, 2010, at 6:43 AM, Albert Graef wrote: > Evan Cheng wrote: >> I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. > > Jeffrey apparently fixed that now, I'm going to test against trunk asap. > > Albert > > -- > Dr. Albert Gr"af > Dept. of

On Saturday 06 February 2010 02:42:47 Evan Cheng wrote: > On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: > >> Does anyone actually using it? > > > > Yes, many LLVM-based projects rely upon TCO to work correctly. > > Ok, that's all I need to know. > > >> I'd prefer to just remove it to

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 Friday 05 February 2010 23:35:15 Evan Cheng wrote: > Does anyone actually using it? Yes, many LLVM-based projects rely upon TCO to work correctly. > I'd prefer to just remove it to clean up the implementation if no one has > any objections. Are you saying that you want to remove LLVM's working TCO and replace it with something that is faster but broken? I think you may

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;

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM

My compiler is generating a bunch of code including the following line: %57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; <i32> [#uses=1] ret i32 %57 The program works fine as long as this isn't a tail call. If I compile via a .ll and insert "tail" by hand, the program segfaults. However, if I make it a tail call and return an undef i8* or void instead

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? >

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

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

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

On Monday 04 January 2010 05:16:40 Jeffrey Yasskin wrote: > On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > LLVM's TCO already handles mutual recursion. > > Only for fastcc functions Yes. > compiled with -tailcallopt, right? If you use the compiler, yes. > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > I believe

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

Jon Harrop wrote: > I've come up with the following minimal repro that segfaults on my machine: Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so