similar to: [LLVMdev] X86 -tailcallopt and C calling conversion

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

Hello, I started off trying to test HLVM (http://www.ffconsultancy.com/ocaml/hlvm/) in a freshly compiled LLVM3.0, and found a few errors have crept into LLVM between revisions 2.7 and 2.8. System info: 2.6.31-23-generic #75-Ubuntu SMP x86_64 GNU/Linux, oprofile version 0.9.3-1.1ubuntu2_amd64 HLVM uses the following code to set "guaranteed" tail call optimization: <code>

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

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

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,

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

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

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

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

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

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

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

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > Hi all, > > As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to

OK, new patch attached. Hopefully in time for 2.7. Chris Lattner wrote: > 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. No its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will