search for: materializationunit

...llvm::orc::SymbolStringPtr>, std::__1::allocator<std::__1::pair<llvm::orc::SymbolStringPtr const, llvm::GlobalValue*> > >) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:320 #19 0x00000001062b8470 in llvm::orc::PartitioningIRMaterializationUnit::materialize(llvm::orc::MaterializationResponsibility) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 #20 0x00000001062e2844 in llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib&) at /Users/igorgomon/dev/third-party/llv...

...t, >>>>> llvm::GlobalValue*> > >) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:320 >>>>> >>>>> #19 0x00000001062b8470 in >>>>> llvm::orc::PartitioningIRMaterializationUnit::materialize(llvm::orc::MaterializationResponsibility) >>>>> at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 >>>>> >>>>> #20 0x00000001062e2844 in >>>>> llvm::o...

...::SymbolStringPtr const, > llvm::GlobalValue*> > >) at > /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:320 > >>>>>>> > >>>>>>> #19 0x00000001062b8470 in > llvm::orc::PartitioningIRMaterializationUnit::materialize(llvm::orc::MaterializationResponsibility) > at > /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 > >>>>>>> > >>>>>>> #20 0x00000001062e2844 in > llvm::orc::MaterializationUni...

...rc::IRCompileLayer::emit(llvm::orc::MaterializationResponsibility R, llvm::orc::ThreadSafeModule TSM) Line 41 C++ libravi.dll!llvm::orc::IRTransformLayer::emit(llvm::orc::MaterializationResponsibility R, llvm::orc::ThreadSafeModule TSM) Line 25 C++ libravi.dll!llvm::orc::BasicIRLayerMaterializationUnit::materialize(llvm::orc::MaterializationResponsibility R) Line 132 C++ libravi.dll!llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib & JD) Line 570 C++ libravi.dll!llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib & JD, std::unique_pt...

...libs 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 lookin...

...alizer functions, since they have to be looked up by name to be run. 3) It doesn't handle platform-specific initializers, e.g. Objective-C registration, which are described by globals in specific sections. The general initializer support patch has changed how initialization is handled. Now all MaterializationUnits, regardless of what kind of program representation they wrap (IR, object files, ASTs, etc.) can now declare an optional "initializer symbol". Instances of the new Platform class (see include/llvm/ExecutionEngine/Orc/Core.h) are notified whenever MaterializationUnits are added to a JITDyl...

Hi, I am still on LLVM v6 as v7 ORC api changes were not backward compatible. Has the ORC api stabilized now with v8, or is it still under flux? Thanks and Regards Dibyendu

Hey Lang, Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O< With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file was loaded by another proce...

Hi, Lang As a starter using LLVM JIT to improve OLAP execution engine performance, I'm very glad to hear that. I can't find some useful document help me get start to use the new ORC JIT API quickly. Only can find some examples how to use it, but don't know the internal from low level, and very blurred to design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT more

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

...stency of symbol names is a requirement for ORC to work. You could try hooking into the orc::Platform API for this: https://github.com/llvm/llvm-project/blob/ec29538af2e0886a65f479d6a533956a1c478132/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1062 The notifyAdding method will be called for each MaterializationUnit added to the JIT, which gives you an opportunity to iterate over the symbols that it provides and record them. Regards, Lang. On Mon, Aug 17, 2020 at 11:16 PM Gaier, Bjoern <Bjoern.Gaier at horiba.com> wrote: > Hey Lang, > > > > Oh shoot… seems like I oversaw it… Sorry so...

...ourceManager* -- A listener interface to be notified when resources associated with a given key should be removed. Each JITDylib will have a default tracker (accessible via JITDylib::getDefaultResourceTracker), and allow creation of new trackers (via JITDylib::createResourceTracker). When adding a MaterializationUnit to a JITDylib (with JITDylib::define, or a Layer's add method) you can optionally specify a tracker to associate with that unit. If no tracker is specified the default tracker for the target JITDylib will be used. A single tracker can be associated with multiple units the remove and transferTo...

Hello, I recently hit an issue when JIT'ing my generated IR using llvm::orc::LLJIT. My IR contains the following definition of a global variable: > $_ZZ23TestStaticVarInFunctionbE1x = comdat any > @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local global i32 123, > comdat, align 4 > And in my host process, there exists the same symbol. I would expect LLJIT to resolve the

...notified when resources >> associated with a given key should be removed. >> >> Each JITDylib will have a default tracker (accessible via >> JITDylib::getDefaultResourceTracker), and allow creation of new trackers >> (via JITDylib::createResourceTracker). When adding a MaterializationUnit to >> a JITDylib (with JITDylib::define, or a Layer's add method) you can >> optionally specify a tracker to associate with that unit. If no tracker is >> specified the default tracker for the target JITDylib will be used. A >> single tracker can be associated with multi...

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

Hi Bjoern, Did you see my previous reply? There's no way to do this currently. ORC assumes you know all the symbols, > since you added the modules defining them. > For testing / debugging you can dump the modules to stderr using > ExecutionSession::dump, but that's about it. > Do you want the symbols for diagnostic purposes, or some other reason? Regards, Lang. On Mon, Aug

Hi Andres, Postgres uses removable code support and Orcv1. I does make me quite > worried to see a phase where there'll be no viable way of using both in > llvm. Why isn't the right answer here to at lest develop the > replacement as a set of patches / as a branch that then can be merged as > a whole / shortly after each other, rather than just starting to develop > a

...n all of them. (2) You shouldn't issue a call to ExecutionSession::lookup from inside tryToGenerate: The tryToGenerate method is called under the session lock, but ExecutionSession::lookup should only be called outside the lock. Instead of issuing the lookup in place you should write a custom MaterializationUnit and issue the lookup from its materialize method. -- Lang. On Wed, Sep 23, 2020 at 1:02 AM Gaier, Bjoern <Bjoern.Gaier at horiba.com<mailto:Bjoern.Gaier at horiba.com>> wrote: Hi Lang, Thank you for your answer! This helped me again a lot!! Also that ResourceTracker is a really nea...

Hi Lang, Thank you for your answer! This helped me again a lot!! Also that ResourceTracker is a really neat feature! Looking forward to it! :3 I changed the title cause… there is another issue I have (sorry about that…) I’m finally allowed to investigate the ORC JIT for integration into our system, which meant I got a few days to actually play around with it. However, another problem arise

Hey Lang, > Do you mean that the object file is produced by another process and is being loaded into your JIT process for execution, or that you want your JIT to produce code for several different processes? These are different problems with different solutions. I'll wait until I understand your use case to answer further. In the current state we don’t have a JIT only an handcrafted object