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/