similar to: [LLVMdev] Tail calls not working with LLVM 2.8

Jon Harrop wrote: > I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows > so I think TCO isn't working. Have there been any obvious changes that would > cause this? FWIW, Pure uses TCO as well and that works fine with LLVM 2.8, both with the JIT and with statically compiled code, at least on x86_64. -- Dr. Albert Gr"af Dept. of Music-Informatics,

Jon Harrop wrote: > I've come up with the following minimal repro that segfaults on my machine: Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so

On Sun, Nov 29, 2009 at 2:19 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > Jon Harrop wrote: >> I've come up with the following minimal repro that segfaults on my machine: > > Jon, were you able to resolve this? > > FWIW, TOT is causing all kinds of weird segfaults related to tail calls > in my Pure interpreter, too (at least on x86-64). In my case these

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

Which of LLVM's backends support TCO? It seems to work on x86 and x64 but what about ARM etc.? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Wednesday 25 November 2009 19:19:28 Jon Harrop wrote: > I'm using LLVM 2.6. Anyone recognise this as a bug in TCO fixed since then > or should I try to boil it down and submit it? I've come up with the following minimal repro that segfaults on my machine: define fastcc i32 @g({i32, {i32, i32}}) { %1 = extractvalue {i32, {i32, i32}} %0, 0 %2 = extractvalue {i32, {i32,

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

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,

My compiler is generating a bunch of code including the following line: %57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; <i32> [#uses=1] ret i32 %57 The program works fine as long as this isn't a tail call. If I compile via a .ll and insert "tail" by hand, the program segfaults. However, if I make it a tail call and return an undef i8* or void instead

Jeffrey Yasskin wrote: > Try batch compiling with the large code model. (llc -code-model=large) > If that also causes tail calls to break, then I did something wrong in > fixing far calls in the JIT. Jeffrey, I took a closer look at this now, and all the TCO-related weirdness I see in the Pure interpreter is indeed related to your commit in r88984 ("Make X86-64 in the Large model

Albert Graef <Dr.Graef at t-online.de> writes: > On 06/21/2012 04:22 PM, Óscar Fuentes wrote: >> About the "many features" that cmake lacks, can you provide a list, >> please? > > Generally it works fairly well, but here are some differences to the > autoconf-based build I noticed: > > - No 'make uninstall'. That is a real deal breaker if you

Nick Lewycky wrote: > Can you prepare a standalone testcase that demonstrates the problem? See > unittests/ExecutionEngine/JIT/*.cpp to get your started. Probably. I'd essentially have to replicate some minimal runtime environment and IR as created by the Pure interpreter. That's doable, but very tedious and will probably take a while. The problems are easy to reproduce by grabbing

Duncan Sands wrote: > Do ordinary users need to have cmake if they want to build llvm? > If so, that's bad because they'll have to install it (unlike the > current setup, where only very standard tools are needed). That's not the only problem with cmake. The autotools may be a big and ugly beast, but that's because they're trying to solve a big and ugly problem for

On Aug 25, 2009, at 12:24 PM, Albert Graef wrote: > Trunk (r80020): > raw_fd_ostream(const char *Filename, std::string &ErrorInfo, > unsigned Flags = 0); > > It would be helpful to emulate the LLVM 2.5 variant of the constructor > on both 2.6 and trunk, so that frontend developers don't have to code > against three different versions of the

Eli Friedman wrote: > This isn't first-hand, but from what I remember hearing on IRC, > putting llvm into shared libraries caused a ridiculous explosion in > dynamic linking (and therefore startup) times. So there is no option > to make shared libraries, at least at the moment. Well, by tweaking configure and make options, I've managed to build LLVM 2.2 shared libraries on

Hello, in order to get ready for the upcoming LLVM 3.1 release, I checked out the 3.1 Release branch. However, unlike with LLVM 3.0, `llvm-config --libfiles` now also reports files that belong to targets that I did not build (and that are thus not available). Is this expected? Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL:

It's not tested anywhere, so it probably breaks all the time everywhere. :( I see code trying to support it in: X86 and PowerPC (with `grep -r TailCall lib/Target/`). On Tue, Dec 8, 2009 at 12:42 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Which of LLVM's backends support TCO? It seems to work on x86 and x64 but what > about ARM etc.? > > -- > Dr Jon

Dear All, The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X. The following patch seems to fix it (it adds a missing include file to get WeakVH defined). Has anyone else seen this breakage, or is it possible that I've got the wrong branch checked out? -- John T. Index: lib/Transforms/Scalar/DeadStoreElimination.cpp

Albert Graef <Dr.Graef at t-online.de> writes: [snip] > Here are some points worth considering: > http://www.remlab.net/op/cmake.shtml (Some of these may already be > addressed in newer cmake versions, I haven't checked recently.) Albert, Some points you mention on your web page are solved. Others are not applicable to LLVM. Others can be fixed within CMake itself (with some

Ok, I attached it to the bug. For reference, here's what I'm using on unix as a workaround as long as this is not fixed: llvm-config --libfiles | xargs -n 1 -I {} sh -c 'test -f {} && echo {}' On Tue, May 15, 2012 at 1:07 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > On 05/13/2012 02:46 AM, Keno Fischer wrote: > > Currently, there's a regression