similar to: [LLVMdev] -fPIC troubles on Linux x86 (32 bit)

Albert, > The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure interpreter > (on Linux). See, e.g.: Please fill a PR in the LLVM bugzilla, so this issue won't get lost. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

Mikhail Glushenkov wrote: > I removed the '-relocation-model' bit from the default invocation > string for llc. To pass arguments to llc, use the new "-Wllc" > option. I'd say that this is the proper solution, even though it breaks backward compatibility on x86_64. But given that llvmc is still considered experimental, better do it now than later. ;-) Thanks a lot

Jeffrey Yasskin wrote: > See Owen's email about docs for the 2.6 release, but it's really not > that hard to keep up with trunk. I recently merged trunk LLVM into > Unladen Swallow, and the changes I needed to make are at > http://code.google.com/p/unladen-swallow/source/detail?r=724. Thanks Jeffrey, that was really very helpful! I have Pure working with both the LLVM 2.6

According to the FAQ llvmc is considered experimental/unsupported. But FWIW, here's an issue I found while trying to use it on 32 bit x86 systems. tools/llvmc/plugins/Base/Base.td hardcodes the -relocation-model=pic option into invocations of llc: def llc : Tool< [(in_language "llvm-bitcode"), (out_language "assembler"), (output_suffix "s"), (cmd_line

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

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,

On Monday 09 June 2008, Albert Graef wrote: > Unfortunately, that approach doesn't work on x86-64 with LLVM 2.2, > since some parts of the LLVM JIT apparently contain non-relocatable > code; I hope that this will be fixed in the forthcoming LLVM 2.3. Unfortunately it's not fixed in 2.3 :( I made a patch ([1]) for 2.2 and gave it to one of the developer, I guess he forgot about

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

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

Albert Graef wrote: > One thing I noticed is that writing LLVM assembler code (print() > methods) seems to be horribly slow now (some 4-5 times slower than in > LLVM 2.5). This is a real bummer for me, since Pure's batch compiler > uses those methods to produce output code which then gets fed into llvmc. Let me follow up with some concrete figures. Unfortunately, I don't have

Cyrille Berger wrote: > Unfortunately it's not fixed in 2.3 :( That's indeed unfortunate. On x86-64 the Pure interpreter currently is a 7MB behemoth, and most of that is LLVM. ;-) On 32 bit I have all that stuff in a separate runtime library, resulting in a 27K interpreter executable. It goes without saying that this makes a world of a difference. I don't care if LLVM is a shared

Óscar Fuentes wrote: > Some points you mention on your web page are solved. Which ones? (Just curious.) > Others are not applicable to LLVM. That might be the case now, but the lack of even basic functionality in some areas (in particular, no advanced feature checks, no make dist/distcheck, no make uninstall, lack of useful trace options when something goes wrong during a build, arcane

mriou wrote: > Using the sin(x) and cos(x) functions work though, only the ones included in > the main file don't. So I'm a bit puzzled... Did you link your executable with -rdynamic? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW:

Chris Lattner wrote: > Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Here are two typos I noticed: s/improvmenets/improvements/ s/GFortan/GFortran/ -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

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,

On 07/05/2011 08:42 PM, Talin wrote: > 2) However, I don't think we should do this unless we can identify at > least one other customer other than myself - mainly because I don't want > the design decisions to be too tailored to my specific use cases. Pure would be another candidate, so I'd be interested in such a toolbox as well, especially in the synchronization primitives

Hi Anton, On 05/08/2012 05:05 PM, Anton Korobeynikov wrote: > I believe examples/ExceptionDemo contains sample code which sets > TargetOptions flags. > In particular, llvm::EngineBuilder class has setTargetOptions() method > which does all necessary magic here. Cool, that's certainly easy enough. :) Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University

On 05/12/2012 04:22 AM, Keno Fischer wrote: > 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? I can confirm this. I always build LLVM with configure

On 05/13/2012 02:46 AM, Keno Fischer wrote: > Currently, there's a regression in llvm-config in both the 3.1 Release > branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The > attached patch fixes that. It would be great if this could be reviewed > and still integrated into 3.1. I'm giving this a bump as that PR is still listed as open and unassigned. Keno, I think