similar to: [LLVMdev] Tail Call Optimization

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

On Wed, Sep 18, 2019, 2:39 PM Steven Wu <stevenwu at apple.com> wrote: > > > On Sep 18, 2019, at 10:24 AM, Steven Wu <stevenwu 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

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

Hi Dwight, Welcome to LLVM-dev! A few comments below. Cc'ing a few people who hopefully can add 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

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

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 most

I don't know if GuaranteedTailCallOpt is in anyone's plans. It might be a good idea to implement some time. I am not sure what GHC's exact needs are, though. Cameron On Jun 17, 2011, at 1:49 PM, Karel Gardas wrote: > > Hello Cameron, > > thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of

I have an issue with the OCaml build system and the ExecutionEngine. PR2128 has a patch to change the Interpreter to use libffi. This breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't try to link with libffi, even though llvm-config knows that we should: $ Debug/bin/llvm-config --ldflags interpreter -L/home/nicholas/llvm-commit/Debug/lib -lpthread -lffi -ldl -lm

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

Trying to get the Pure compiler to work with LLVM 3.1, I've run into a problem. The release notes say: "Target specific options have been moved from global variables to members on the new TargetOptions class, which is local to each TargetMachine." Unfortunately, they don't say anything about how to fix existing source to work around this. In my application I create a JIT

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,

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

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

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

On 2009-01-19, at 13:50, Nick Lewycky wrote: > I have an issue with the OCaml build system and the ExecutionEngine. > > PR2128 has a patch to change the Interpreter to use libffi. This > breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't > try to link with libffi, even though llvm-config knows that we should: > > $ Debug/bin/llvm-config --ldflags

Hello Cameron, thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of the development plans already? If not, then what do you think is the complexity of such work? Thanks! Karel On 06/17/11 10:41 PM, Cameron Zwarich wrote: > They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative

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