runtime library for jitted code

Dear All,

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 ‘-rdynamic’ option as suggested in the tutorial to resolve required functions at runtime. However it is not an option, I am stuck to Windows and Visual C++. One possibility that I have found is to create llvm::Function objects and use ExecutionEngine::addGlobalMapping to map them to the implementations. This works fine but is quite labour-consuming since every library function required used in jitted code needs to be mapped. Does anyone know a better way?

Thanks,
Victor

Hello, Victor

found is to create llvm::Function objects and use
ExecutionEngine::addGlobalMapping to map them to the implementations. This
works fine but is quite labour-consuming since every library function
required used in jitted code needs to be mapped. Does anyone know a better
way?

Theoretically you should be able to load the .dll into address space
of the application, "register" it and stuff should magically work. I
am not sure whether this functionality obtained much care recently, so
some bugfixing might be needed.

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 '-rdynamic'
option as suggested in the tutorial to resolve required functions at
runtime. However it is not an option, I am stuck to Windows and Visual
C++.

Well, backlinking doesn't work on Windows, but you can create a dll for
your runtime and use LLVM's dynamic library interface to load that dll.
I'm doing it that way in my project (http://pure-lang.googlecode.com/,
search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
on Windows.

Albert

Albert Graef <Dr.Graef@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
to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic'
option as suggested in the tutorial to resolve required functions at
runtime. However it is not an option, I am stuck to Windows and Visual
C++.

Well, backlinking doesn't work on Windows, but you can create a dll for
your runtime and use LLVM's dynamic library interface to load that dll.
I'm doing it that way in my project (http://pure-lang.googlecode.com/,
search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
on Windows.

The OP says that he wants to link to a dll coded in C++. Isn't name
mangling the main problem here?

Name mangling is not a problem, I just wanted to figure out if it is necessary to declare all functions from the runtime library and map them to the addresses manually.

Victor

2009/6/15 Óscar Fuentes <ofv@wanadoo.es>

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@t-online.de>

Victor Zverovich wrote:

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?

Yes, basically you need to construct the IR for a body-less function
with external binding, the JIT will then try to resolve it when you call
the function.

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 support for Visual C++ style (de)mangling in LLVM or related project? In any case I think it won’t be difficult for me to write such a converter from mangled names to LLVM function declarations.

Best regards,
Victor

2009/6/15 Óscar Fuentes <ofv@wanadoo.es>

If you're simply looking to write a generator that spits out LLVM code
that you can link into your language, you should be able to throw
together something that uses the "undname.exe" utility from Visual
Studio that demangles all the names listed in a provided file.
Something like a script that's part of your build process and
generates the necessary stub code to link in by using dumpbin and
undname.

If you're interested in doing this "on the fly" during JIT for some
reason, there's the Microsoft APIs UnDecorateSymbolName and _unDName.
The first is a publicly documented API, the second is internal but
more feature rich. An Internet search should provide insight into
these. There's also open-source Wine code for _unDName I believe.

Victor Zverovich <victor.zverovich@googlemail.com> writes:

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 support for Visual C++ style (de)mangling in LLVM or
related project? In any case I think it won't be difficult for me to write
such a converter from mangled names to LLVM function declarations.

As long as the functions' arguments an return types are simple enough,
it seems doable. But have you something in mind for cases such as

AClass foo(SomeOtherClass other);

?

Unfortunately I have no idea how to to properly declare such prototype in LLVM so that it was compatible with the code generated by Visual C++. So I am considering only simple cases (numeric types and pointers).

Victor

2009/6/16 Óscar Fuentes <ofv@wanadoo.es>