search for: tailcallopt

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

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? > > In X86IS...

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, 2010, at 7:32 PM, Albert Graef wrote: > 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...

...ince both if us have forgotten recently. I can take a stab at the second one if you don't have time. Thanks, Jeffrey On Friday, February 5, 2010, Evan Cheng <evan.cheng at apple.com> wrote: > Hi all, > > I've added tail call optimization to x86. This is different from what -tailcallopt does, which forces fastcc function to be tail callable. My changes detect opportunities to do tail call without having to change the ABI. > > I've looked at the codegen of -tailcallopt and it doesn't look all that good. Running it as a llcbeta option shows it significantly pessimize c...

Hi all, I've added tail call optimization to x86. This is different from what -tailcallopt does, which forces fastcc function to be tail callable. My changes detect opportunities to do tail call without having to change the ABI. I've looked at the codegen of -tailcallopt and it doesn't look all that good. Running it as a llcbeta option shows it significantly pessimize code in mo...

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: ht...

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 &g...

Hi Dwight Thanks for the feedback. For the issue you reported, there has been few reviews trying to tweak the -mllvm option when using legacy LTO interfaces (myself included) but it never got enough traction to moving forward. Note how -tailcallopt is implemented as a -mllvm flag means that it is a debug option and probably not well tested. The option is also not stable which means it can be renamed without notification. I also feel like passing -tailcallopt in the linker stage is kind of fragile. It is better to create an attribute (on func...

...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 fact, most functional language implementations will rely on TCO. If you can make this work reliably on all supported platforms without needing special flags, that would be welcome. Otherwise please keep the flag. (That...

...tc. So if you could write this part, I'd appreciate it. Evan > > Thanks, > Jeffrey > > On Friday, February 5, 2010, Evan Cheng <evan.cheng at apple.com> wrote: >> Hi all, >> >> I've added tail call optimization to x86. This is different from what -tailcallopt does, which forces fastcc function to be tail callable. My changes detect opportunities to do tail call without having to change the ABI. >> >> I've looked at the codegen of -tailcallopt and it doesn't look all that good. Running it as a llcbeta option shows it significantly pe...

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

...TargetOptions references it - as noted already in the list. --> #include "llvm/Target/TargetOptions.h" #include <iostream> extern "C" { using namespace std; void enable_tail_call_opt() { cout << "Enabling TCO" << endl; //llvm::PerformTailCallOpt = true; <-- pre-2.7 name llvm::GuaranteedTailCallOpt = true; } } </code> Compiling 3.0 (but not 2.8 or earlier) I also had to run: touch llvm-3.0.src/bindings/ocaml/llvm/Release/META.llvm to passify make install, since it tried to install metadata, but didn't have any. Troub...

...gt; >> It makes sense to be extra careful at this point. The policy can be >> changed when we enable tail call optimization by default. >>> >>> but i think if it is documented that there will be a incompatibility >>> between >>> modules compiled with tailcallopt on/off that is okay? >>> and this would only happen if someone other than llvm-gcc used llvm >>> as a backend >>> anyway. >> >> Documentation isn't going to be enough. We will do everything >> possible to ensure there isn't abi incompatibility. B...

...within a module? > a little limiting i think. It makes sense to be extra careful at this point. The policy can be changed when we enable tail call optimization by default. > > but i think if it is documented that there will be a incompatibility > between > modules compiled with tailcallopt on/off that is okay? > and this would only happen if someone other than llvm-gcc used llvm > as a backend > anyway. Documentation isn't going to be enough. We will do everything possible to ensure there isn't abi incompatibility. But at this point, it's important the patch...

...nwu at apple.com> wrote: > > Hi Dwight > > Thanks for the feedback. For the issue you reported, there has been few > reviews trying to tweak the -mllvm option when using legacy LTO interfaces > (myself included) but it never got enough traction to moving forward. Note > how -tailcallopt is implemented as a -mllvm flag means that it is a debug > option and probably not well tested. The option is also not stable which > means it can be renamed without notification. > > > Digging out the patch Teresa once pointed out to me: > https://reviews.llvm.org/D19015 > It...

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

...info on some of the specific issues here. Teresa On Wed, Sep 18, 2019 at 9:04 AM Dwight Guth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I am lead developer of a project that is using LLVM to implement an > ahead-of-time compiled functional language. We use llc -tailcallopt to > ensure that functions that end in a tail call are compiled to a tail call > at the machine level, because we have a number of cases in our interpreter > where functions with different function signatures call one another in > deeply nested recursive calls. > Maybe a naive quest...

I was playing with optimization switches to llc to see how fast I could get it to compile but it keeps barfing. Tinkering indicates that llc barfs particularly when -tailcallopt is given in combination with other flags. For example, without -tailcallopt works in a couple of ways: $ llc -O0 -f aout.bc -o aout.s $ llc -O0 --regalloc=local -f aout.bc -o aout.s But fails with -tailcallopt with different error messages in each case: $ llc -O0 -tailcallopt -f aout.bc -o aou...

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

...n <= 0 ? "DONE" : b(n - 1) >> end >> >> def b(n) >>   n <= 0 ? "DONE" : a(n - 1) >> end >> >> a(10000000) >> >> Boom! > > LLVM's TCO already handles mutual recursion. Only for fastcc functions compiled with -tailcallopt, right? http://llvm.org/docs/CodeGenerator.html#tailcallopt I believe gcc manages to support tail calls in many more cases, and this restriction in llvm confuses lots of newcomers. It would be very worthwhile if someone wanted to remove it.