similar to: [LLVMdev] 3.1 API Breakage

Hello Albert, > Any help is much appreciated. 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. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

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,

Hi, I am trying to implement a scenario similar to running ExceptionDemo.cpp with parameter -1 (where the JITed code calls the C++ function which throws an exception) Different from the given example I am using IRParser instead of IRBuilder. I can successfully catch the exception in Linux but the program crashes in Mac and Windows. The code is similar to as follows: ### The test.cpp :

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

Kenneth Uildriks wrote: > It seems that a client application needs to call > InitializeNativeTarget or LLVMInitializeNativeTarget before doing any > JITting. Unfortunately, LLVMInitializeNativeTarget is defined static > inline and does not appear in the .a files; thus a client not written > in C or C++ trying to JIT cannot link to the library and call >

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

It seems that a client application needs to call InitializeNativeTarget or LLVMInitializeNativeTarget before doing any JITting. Unfortunately, LLVMInitializeNativeTarget is defined static inline and does not appear in the .a files; thus a client not written in C or C++ trying to JIT cannot link to the library and call LLVMInitializeNativeTarget that way. It can call a target-specific library

Owen Anderson wrote: > On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: >> >> You mean like this subject ? >> >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html > > Notice the sender line on that email... ;-) Yes, you indeed announced that change, but as John rightfully remarked, the announcement gave little detail. For LLVM users like me,

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

Ó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

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

Albert and Anton, thanks for all the answers. I tried to load a DLL with DynamicLibrary::LoadLibraryPermanently and it works perfectly, so there is no need to use ExecutionEngine::addGlobalMapping. However Function objects still need to be constructed since they are required when creating a call, right? Victor 2009/6/15 Albert Graef <Dr.Graef at t-online.de> > Victor Zverovich wrote:

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

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

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