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

The LLVM 1.5 is out! Get it here: http://llvm.cs.uiuc.edu/releases/ or read about it here: http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew This release adds several new major features to the LLVM compiler, allows it to be used in domains where it couldn't before (e.g. for functional languages), supports new targets, generates faster code, and is much easier to port

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 recently checked in the X86 support for tail calls. Hurray!!! And thank you. Marshall

You can skip this first and second paragraph if you just want to get to the description, the 'real' question I want is the bottom most paragraph and may still make enough sense to read without reading everything else, but there are a few other hidden questions and opinions being asked in the rest of it. In this little scripting language I am making is basically going to be a C with Actors

In order to test the tail call optimization i created quite a few .ll files and added them to the SingleSource directory in the test-suite. For example llvm-test/SingleSource/Tailcall/tailcall1-2.ll. Since i don't want opt to inline the tailcalls away :) i changed the rules in the Makefile situated in the TailCall directory. I want to compare the output of a file compile with normal llc with

We used to have an LLVM-IR pass did tail duplication (http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_29/final/lib/Transforms/Scalar/TailDuplication.cpp) It was not used and went away with 3.0. The documentation is out of date. commit f940a1a869b4fe6f857e7fd8aeb97e7b7e9b390e Author: Rafael Espindola <rafael.espindola at gmail.com> Date: Tue Aug 30 23:03:45 2011 +0000 Remove the

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

On 2009-02-24 12:35, Jon Harrop wrote: > On Tuesday 24 February 2009 00:16:37 Dan Gohman wrote: > >> On Feb 23, 2009, at 5:59 AM, Anton Korobeynikov wrote: >> >>> This is not true in general and highly target- and CC- dependent. For >>> example, you can ran out of registers and then your struct can be >>> passed >>> partly in registers

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

They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative about when to use tail calls, and doesn't support GuaranteedTailCallOpt, which might be necessary for GHC. Cameron On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > > John, > > I've moved with patches to HEAD and unfortunately the comments about > disabling tailcalls do not go

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

John, I've moved with patches to HEAD and unfortunately the comments about disabling tailcalls do not go away with this update. Please see ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line 1208 and later. It looks like man can use -arm-tail-calls, but one never knows how good it is since the comment tells it clearly: // Temporarily disable tail calls so things

On Wed, 18 May 2005, Chris Lattner wrote: > Yup, something like this should work. Two comments though: > 2. I haven't done much testing with the JIT and tail calls. I wouldn't be > suprised if there are minor issues that need to be fixed. I will try > to take a look and see what remains to be done over the next couple of > days. As I expected, there were issues. I

On Thu, 15 Jul 2004, Reid Spencer wrote: > On Thu, 15 Jul 2004 18:05:21 -0500 (CDT) > Chris Lattner <sabre at nondot.org> wrote: > > > BTW, for those who are interested in the differences between 1.2 and CVS, > > check out: http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html#whatsnew > > It might be a good idea to add a check-in script that puts the latest >

On Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

On Oct 4, 2007, at 2:31 PM, Arnold Schwaighofer wrote: > > On 4 Oct 2007, at 00:22, Evan Cheng wrote: >>> ifeq ($(ARCH),x86) >>> LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call- >>> opt- >>> align-stack >> Please remove -regalloc=local -fast. We want to test this patch >> separately. > > just did a test with >

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

On Sep 25, 2007, at 12:01 AM, Arnold Schwaighofer wrote: >>> FastCC use to be caller pops arguments so there was no stack >>> adjustment after the >>> call to qux. Now FastCC has callee pops arguments on return >>> semantics >>> so the >>> x86 backend inserts a stack adjustment after the call. >>> >>> _array: >>>

Implementing tail call opt could look like the following: 0.)a fast calling convention (maybe use the current CallingConv::Fast, or create a CallingConv::TailCall) 1.) lowering of formal arguments like for example x86_LowerCCCArguments in stdcall mode we need to make sure that later mentioned CALL_CLOBBERED_REG is not used (remove it from available registers in callingconvention for