similar to: [LLVMdev] Re: Proper tail calls support in CVS

I recently checked in the X86 support for tail calls. This is documented briefly here: http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html#tailcalls If you're interested in this, please try it out and let me know if you hit any problems. I know of only one program in the llvm-test suite that it causes a problem for (which I'll have fixed shortly). -Chris -- http://nondot.org/sabre/

Hi Mark, On 2013-08-02 04:11, Mark Seaborn wrote: > That note in the documentation seems to be incorrect, because LLVM > will do tail call optimisations on at least x86 when using the "ccc" > calling convention. For example: > > $ cat tail_call1.c > void foo(int arg); > void bar(int arg) { > foo(arg); > } > > $ clang tail_call1.c -S -o - -O2 >

I have been working on adding proper tail (via `become`) to rustc. I was able to make them work (some parts of the type checker aren't implemented yet). However, I ran into an LLVM-related problem. LLVM claims to support proper tail calls when fastcc is used — but only on i386, x86-64 and PowerPC. Is this accurate? Will proper tail calls be supported on WebAssembly? Are they supported on

Hi Marshall, LLVM *is* cool .. just not on cygwin! :) Sorry for the sad state of the cygwin build. I had hoped to have it cleaned up by now but many other things have been taking my time. Although the build has been succeeding in recent days, I'm not sure it will buy you anything. NONE of the nightly tests pass on cygwin. Until I can get some time to figure out why that is happening, I doubt

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

On 1 August 2013 00:11, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > we've published an initial version of the PNaCl bitcode reference > > manual online - > > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl > > bitcode is a restricted subset of LLVM IR. > > > > Any comments would be

Hi, I'm looking into LLVM, and I must say it looks supremely cool. However, I'm having a hard time getting anywhere with it, since I don't have a linux machine here, and cygwin seems like a bit of a second-class citizen. The instructions to build the cygwin binaries are outdated, so I have to just make some guesses as to what the right thing to do is, and I'm apparently not

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>

On Wed, 18 May 2005, Morten Ofstad wrote: > Alexander Friedman wrote: >> How do I tell the code generator to enable tail calls on the X86? >> Since it is part of a library, I cannot pass a command line argument. > > Here is a snippet from our code which might help you ;-) > > const char *args[] = { "-disable-pattern-isel", "false", 0 }; >

Marshall Spight wrote: >>FYI, work progresses on the Win32 native port which you might also find >>interesting. It might even get done before the cygwin stuff. Jeff Cohen >>is working on that. Perhaps he can indicate the status of that effort. >> >> > >I recall reading on the llvm archives somewhere that there are significant >performance issues with the

> > ifeq ($(ARCH),x86) > > LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call-opt- > > align-stack okay i ll do another round of testing with LLCBETAOPTION := -tail-call-opt -tail-call-opt-align-stack > Please remove -regalloc=local -fast. We want to test this patch > separately. Can you explain the advantages / disadvantages of -tail- >

Resent, to the list this time instead of David (sorry for the duplicate)... On Thu, Nov 12, 2009 at 9:57 PM, David Terei <davidterei at gmail.com> wrote: > I've run into some issues with tail calls in the past, make sure you > are doing the following: > > 1. Call should be marked with tail (obviously) > 2. Next statement after tail call should be 'return void'

The ref manual states: The optional "tail" marker indicates whether the callee function accesses any allocas or varargs in the caller. If the "tail" marker is present, the function call is eligible for tail call optimization. Note that calls may be marked "tail" even if they do not occur before a ret instruction. Does "eligible" in the above mean that some

I've run into some issues with tail calls in the past, make sure you are doing the following: 1. Call should be marked with tail (obviously) 2. Next statement after tail call should be 'return void' 3. Use fast call convention for tail calls 4. Make sure the function you are calling doesn't use the 'noreturn' attribute. 5. Turn on tail calls in llc (if using the static

Hi Jon, > >From what I have understood of the LLVM docs about when tail calls get > eliminated on x86 and x64 it should be a tail call, yes. > > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > . Caller and callee have the calling convention fastcc. > . The call is a tail call - in tail position (ret immediately follows call and > ret uses value of call or

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

On Mar 16, 2010, at 6:46 PM, Scott Ricketts wrote: > I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: > > 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the

Arnold Schwaighofer wrote: > Take this with a grain of salt or two since i have never done it ;) > but i guess that setting those globals is what > cl::ParseCommandLineOptions does in lli/llc.cpp. I can confirm that this is actually how it works (fastcc on the function + setTailCall on the call instruction + llvm::PerformTailCallOpt = true). I might add that of course you also have to

Sent from my iPhone On Aug 8, 2007, at 10:46 AM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com > wrote: > Hi Anton and Dale > first thanks for your answers. > > On 8 Aug 2007, at 16:43, Anton Korobeynikov wrote: > >> Hello, Arnold. >> >>> Is there a way to indicate that the register the tail call >>> instruction uses as destination

Hello list, i am currently trying to implement tail call optimization in the X86 backend , so far i have it working for cases (modulo many unknown bugs :) where the tail called function is a destination within the source file and frame pointer elimination is performed. i implemented it as a dagcombiner transformation running in post legalized phase within the