New JIT APIs

Good to know … I started 2 years ago and used the tool “lli” as an JIT example, but didn’t care about the atexit handling in details. Is in the meantime a documentation available about the “MCJIT API” ? I’m not a specialist for compiler construction … so it is a PITA for me to go through the djungle of class definitions (most of them w/o any comments explaining their semantics). Is it not possible to develop a user interface for the JIT compile API comparable to the user interface of e.g. CLANG ?? Thanks so far Armin

From: Armin Steinhoff [mailto:armin@steinhoff.de]
Subject: Re: [LLVMdev] New JIT APIs

is
delete EE; // execution engine
llvm_shutdown();
sufficient ?

AFAICT, llvm_shutdown() must not be called unless you reach a point where LLVM will not be used again by the process (e.g., termination), as it destroys statically allocated objects. We delete the ExecutionEngine (which automatically deletes TargetMachine and Module) after each compilation. The LLVMContext and IRBuilder objects are deleted after some configurable number of compilations, in order to avoid unbounded growth in the constant pool.

We're currently using LLVM 3.3 in production (due to performance regressions in newer versions), so I don't know if some other scheme is appropriate for current levels.

- Chuck

> From: Armin Steinhoff [mailto:armin@steinhoff.de]
> Subject: Re: [LLVMdev] New JIT APIs

> is
> delete EE; // execution engine
> llvm_shutdown();
> sufficient ?

AFAICT, llvm_shutdown() must not be called unless you reach a point where
LLVM will not be used again by the process (e.g., termination), as it
destroys statically allocated objects.

At least in theory all those lazy static objects should be re-initialized
when they're first used after a call to llvm_shutdown (bits of the code
clearly intend this to be a supported scenario) but it's probably
under-tested & I'm not sure if people have ideas about killing it off (so
I'm not sure if the right path forward is to avoid relying on that behavior
so it can be killed, or to fix the bugs).

We delete the ExecutionEngine (which automatically deletes TargetMachine
and Module) after each compilation. The LLVMContext and IRBuilder objects
are deleted after some configurable number of compilations, in order to
avoid unbounded growth in the constant pool.

Yeah, I don't believe the context's constant pool growth has been addressed
even in recent versions.

Hi Chuck,

Just a heads up: The patch is now up for review on llvm-commits. If you have comments related to the patch please post them in that thread.

Cheers,
Lang.

> We're currently using LLVM 3.3 in production (due to performance regressions in newer
> versions), so I don't know if some other scheme is appropriate for current levels.

Do you have any insight into what regressed?

The differences were noted using our standard in-house benchmarks, and we haven't really had the time to do much EMON- and instruction-level research into the differences (the product isn't out the door yet). One of the problems may be in register allocation, since there seemed to be more spills and reloads; there's no evidence that MCJIT itself was an issue. We'll be able to start checking out 3.6 (or 3.7) in detail in June or thereabouts.

- Chuck

Hi Chuck,

Thanks for the feedback. I look forward to hearing how the upgrade to 3.6/3.7 goes.

  • Lang.