[LLVMdev] Ahoy JIT Users

Török Edwin edwintorok at gmail.com
Fri Nov 12 23:29:06 PST 2010


On Fri, 12 Nov 2010 17:42:57 -0800
Daniel Dunbar <daniel at zuster.org> wrote:

> Hi,
> 
> I am starting to poke at the LLVM JIT, which seems to be in need of
> some TLC.
> 
> If you are a "sophisticated" JIT user and are using either internal
> APIs (either by integrating with LLVM, or by other C++ tricks), or are
> using obscure or poorly documented public APIs (e.g., why is
> runJITOnFunction exposed?) please make me aware of it!

Hi Daniel,

I don't think I'm using any internal APIs (I'm using EngineBuilder and
ExecutionEngine, not the JIT class directly).
Just tell me when you're done with the MC changes, and I'll test if my
code still works with it.

Some APIs that I use that don't have a unit-test (but I think their
purpose is quite well documented);
 - DisableSymbolSearching
 - InstallLazyFunctionCreator
 - llvm::JITEmitDebugInfo = false (In production code I don't need it,
   so I turn it off to avoid the memory leaks it causes)
 - llvm::DwarfExceptionHandling = false (similarly I don't use/need exc
   handling, so I don't want to spend time and memory to build and emit
   it)

One shortcoming is that even with DisambleSymbolSearching the JIT fails
to be created if it cannot resolve symbols in itself, I usually comment
out that line but I should probably submit a patch that fixes it
properly.
I don't link the JIT with -ldl at all, because I don't allow any
external calls: they are either completely forbidden, or solved to
functions in my code (forwarding to appropriate libc func if needed),
thats why I use the Lazy function creator.
Are your MC patches going to change anything wrt. symbol searching?

Also I use getPointerToFunction as a mean of trying to avoid creating
stubs, (and of course getting pointer to JITed code), and I use
addGlobalMapping (but I see this has a unit-test too).

I do use llvm_start_multithreaded, however it looks like it doesn't
like if I create multiple JITs in parallel so I just use a mutex
around all my use of LLVM APIs for now (they are 99% of the time not
happening in parallel anyway so mutex is no big deal).
However if you want me to test whether your new MCized JIT is completely
thread safe, then I can turn off my mutex, run my unit-test and see
if I get any crashes (or helgrind warnings).

Also take care with relocations on PowerPC, if you exceed 5M then you
need to use a different instruction. The old JIT doesn't know how to
do that so just asserts: LLVM has a patch in codegen that tries the
generate the correct instruction in the first place (and a unit-test
that I think is currently turned off), however if MC will be able to do
proper relocations by substituting the correct instruction (even ifthat
changes code size) like a real linker that would probably be more
reliable.

Best regards,
--Edwin



More information about the llvm-dev mailing list