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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200419/3468f029/attachment.html>
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 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200420/200271a3/attachment-0001.html>
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 at gmail.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/16599353/attachment.html>