similar to: [LLVMdev] runtime library for jitted code

Victor Zverovich wrote: > I am considering a possibility of using LLVM JIT for an algebraic > modelling language. I have already done some prototyping following the > Kaleidoscope tutorial and currently thinking of how to connect the > jitted code to a runtime library (for this language) which I would like > to code in C++. If it was *NIX I would use g++ possibly with

Albert Graef <Dr.Graef at t-online.de> writes: > Victor Zverovich wrote: >> I am considering a possibility of using LLVM JIT for an algebraic >> modelling language. I have already done some prototyping following the >> Kaleidoscope tutorial and currently thinking of how to connect the >> jitted code to a runtime library (for this language) which I would like

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:

On Jul 2, 2009, at 1:05 AM, Carter Cheng wrote: > I am having some difficulties getting the LLVM JIT to resolve extern > "C" functions which I have defined in source file and invoking them > via EE::runFunction() after generating a Function prototype for it. > Is this possible or do I need to generate a .so for my functions are > link against it? If the JIT needs

Hi, I am having some difficulties getting the LLVM JIT to resolve extern "C" functions which I have defined in source file and invoking them via EE::runFunction() after generating a Function prototype for it. Is this possible or do I need to generate a .so for my functions are link against it? Thanks in advanced, Carter. Sorry for the double post but apparently I mistakenly tagged

Hi, The question about the name mangling gave me an idea that it can be used to automate registration of DLL functions. Instead of manually creating Function objects specifying a return type and argument types which is error-prone and time-consuming one can get a list of functions exported from a DLL using Windows API, demangle each name and construct a Function object from it. Is there any

John McCall wrote: > On Jul 2, 2009, at 1:05 AM, Carter Cheng wrote: >> I am having some difficulties getting the LLVM JIT to resolve extern >> "C" functions which I have defined in source file and invoking them >> via EE::runFunction() after generating a Function prototype for it. >> Is this possible or do I need to generate a .so for my functions are

Hi all, My example compiler is working fine on Linux, including the extern'd functions (via -rdynamic flag on linker), but a friend on a MacOS (Darwin) cannot find the extern'd function. LLVM ERROR: Program used external function 'printVar' which could not be resolved! I've read some posts on the web indicating problems with the -rdynamic option on Mac's GCC, but I'm

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:

Hi I hope this is a proper place to put my question. I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. Basically it works just fine but when I try to run extern'ed putchard function it aborts. Please, tell me what am I doing wrong? Here is more information: My PC runs FreeBSD. I've copied the toy source code exactly and didn't change it.

Anton Korobeynikov wrote: > > Hello, > >> ready> ERROR: Program used external function 'putchard' which could not >> be >> resolved! >> Any idea of what could be wrong? > Please make sure you're using C linkage for such functions, due to > mangling the name of > function being emitted is not "putchard". Something like this: >

Dears, I'm trying to call the function that defined in the host application from IR code, but LLVM is saying that there is no such function... I've seen the tutorial of Kaleidoscope, and defined the function as extern "C" { void test1(void) { cout << "test function in the host application \n" ; } } ...in the host application. Would you please let me give any

Renato Golin wrote: > I've read some posts on the web indicating problems with the -rdynamic > option on Mac's GCC, but I'm not sure. What's the Mac-style for that? -rdynamic doesn't exist on OSX, nor should it be needed. Just make sure that you do *not* strip the executable (i.e., avoid strip, install -s, etc.), IIRC that's needed to make dlopening the executable

Hello, > ready> ERROR: Program used external function 'putchard' which could not be > resolved! > Any idea of what could be wrong? Please make sure you're using C linkage for such functions, due to mangling the name of function being emitted is not "putchard". Something like this: extern "C" void putchard(char c) { ... } Or, just provide a mapping

Chris Lattner wrote: > In the end, I consider this to be a yet-another chapter in the > "functional language people don't like LLVM" saga. Yet another counterexample: http://pure-lang.googlecode.com/ LLVM from the ground up, proper tail calls, interactive interpreter, JIT, easy C interface. Works great. :) Without LLVM, I could have never pulled that off in a couple of

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

On Jan 17, 2009, at 1:25 PM, Albert Graef wrote: > Chris Lattner wrote: >> In the end, I consider this to be a yet-another chapter in the >> "functional language people don't like LLVM" saga. > > Yet another counterexample: > > http://pure-lang.googlecode.com/ Hey, this is incredibly cool. I had never heard of pure, nice work! Would you mind writing a

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

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,