ORC JIT Weekly #12

Hi All,

There was only one interesting ORC-specific commit this week: A new example showing how to initialize and de-initialize JITDylibs has been added in llvm/examples/OrcV2Examples/LLJITWithInitializers.

The Extensible RTTI system (https://reviews.llvm.org/D39111) that I posted a while back has landed. While this is not ORC specific, I expect it to be used in upcoming patches to allow ORC clients to check the dynamic type of MaterializationUnits. This can be used during dispatch to prioritize work by type, e.g. prioritizing stubs and other trivial-to-materialize symbols.

Finally, I hope to spend next week working on support for removable code in OrcV2, which is one of the big missing features from OrcV1. I expect the API to end up looking something like this:

using ResourceKey = const class ResourceTracker*;
class ResourceTracker {
public:
// Return the key for this tracker (just its address)
ResourceKey getKey() { return this; }

// Emit all not-yet-emitted symbols covered by this tracker.
Expected emit();

// Remove all symbols covered by this tracker and
// release resources.
Error remove();

// Transfer tracking of all symbols / resources to the
// containing JITDylib’s tracker.
void detach();
};

I’m hoping that usage will look like:

LLJIT J = LLJITBuilder().create();

// No tracker specified. Resources tracked by the containing
// JITDylib’s tracker, and freed when the JITDylib is
// deinitialized.
ExitOnErr(J.addIRModule(sdt::move(UntrackedModule)));

// Explicitly specify tracker. Module symbols can be
// - materialized by calling T->emit();
// - removed by calling T->remove();
// - transfered to the JITDylib by calling T->release();
auto T = std::make_unique();
ExitOnErr(J.addIRModule(TrackedModule, T->getKey()));

Early feedback on this API sketch is welcome. Otherwise I hope to have early reviews / discussion ready in time for next week.

– Lang.

Hi Lang, thanks again for your updates!

The Extensible RTTI system (https://reviews.llvm.org/D39111) that I posted a while back has landed. While this is not ORC specific, I expect it to be used in upcoming patches to allow ORC clients to check the dynamic type of MaterializationUnits. This can be used during dispatch to prioritize work by type, e.g. prioritizing stubs and other trivial-to-materialize symbols.

This is great news! Looking forward to use it for dispatch in the ThinLtoJIT prototype once I resume to my LLVM work.

Hi Stefan,

This is great news! Looking forward to use it for dispatch in the ThinLtoJIT prototype once I resume to my LLVM work.

Yes – I think it will be really handy for that. Hopefully I will get some profiling signposts and logging in to ExecutionSession in the not too distant future too: I think your ThinLtoJIT prototype will make for an interesting in-tree performance stress-test.

– Lang.