[llvm-dev] ORC JIT Weekly #12

[Lang Hames via llvm-dev]

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.

On Mon, Apr 20, 2020 at 1:58 AM Stefan Gränitz <stefan.graenitz at gmail.com>
wrote:

> 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.
>
> On 20/04/2020 07:36, Lang Hames wrote:
>
> 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<SymbolMap> 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<ResourceTracker>();
> 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.
>
> -- https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/16599353/attachment.html>