[LLVMdev] Tail Call Optimization

[David Rogers]

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>
#include "llvm/ADT/StringRef.h" <!-- had to be added, since
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.

  Trouble was that just about all test cases would cause "Stack
overflow" during jit execution -
making me suspect a problem with tail call optimization in LLVM.
Stack overflows didn't happen immediately in 3.0, but happened almost
immediately in 2.8.
Sure enough, reverting to LLVM2.7 fixed the issue and no overflow was observed.

  A more informed failure case for tail call optimization
was posted a year ago, but never answered. I think correctness of the
3.0 and current
implementations of "GuaranteedTailCallOpt" requires re-examination.

~ Dr. David M. Rogers
  Nanobiology Department
  Sandia National Labs

===================
[LLVMdev] X86 -tailcallopt and C calling conversion
NAKAMURA Takumi geek4civic at gmail.com
Tue Jan 4 21:07:26 CST 2011

    * Previous message: [LLVMdev] X86 -tailcallopt and C calling conversion
    * Next message: [LLVMdev] LLVM for ARM target
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello Evan,

I am sorry for my poor question.
s/ccc/default calling conversion/g ;)
("ccc" should be accepted as calling conversion specifier)

When "-tailcallopt" is specified (GuaranteedTailCallOpt),
tailcall optimizer would not touch functions of default calling conversion.


; for example
define void @caller_c() nounwind {
entry:
  tail call void @callee_c()
  ret void
}
declare void @callee_c() nounwind

define fastcc void @caller_f() nounwind {
entry:
  tail call fastcc void @callee_f()
  ret void
}
declare fastcc void @callee_f() nounwind


On {i686|x86_64}-linux without -tailcallopt,
caller_c:
        jmp     callee_c                # TAILCALL
caller_f:
        jmp     callee_f                # TAILCALL


With -tailcallopt, (on x86-64. simila on i686 too)
caller_c:
        pushq   %rax
        callq   callee_c
        popq    %rax
        ret
caller_f:
        pushq   %rax
        popq    %rax
        jmp     callee_f                # TAILCALL


...Takumi
=====================
This is related to a thread from February of 2010 where tailcallopt
began an uncertain future.
=====================

On Feb 5, 2010, at 15:35, Evan Cheng wrote:
>
> 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.

+1 for opportunistically optimizing tail calls in the "ccc" convention
during x86 assembly generation.  This is a desirable feature.

> Does anyone actually using it?  I'd prefer to just remove it to clean up the implementation if no one has any objections.


-1 for removing the guaranteed tail call feature of the "fastcc"
convention.  As others have noted, there are several projects (mine
included) that require the "tail" call site qualifier in the IR
language.


—
j h woodyatt <jhw at conjury.org>
http://jhw.vox.com/