search for: executionsess

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 17, 2020 at 5:19 AM Gaier, Bjoern via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This issue is still not solved for me… > > What can I im...

...! (I was 5 weeks away > but I thought I checked all mails correctly >o<) > > > > I think ORCs assumption is correct, currently I do extract the symbols > which I care about via the modules, but when writing the code I was like > “why do I have to do it like that, when the ExecutionSession already knows > all symbols?” – that is where my question came from. > > However… I’m a bit worried about taking symbols from modules, because some > of the symbols might change later when the code was compiled with the JIT. > So I felt like that the ExecutionSession would been mo...

Hey everyone, is there a way to get the name of all symbols that are stored ("stored" is not the right term - is it?) in my current ExecutionSession? I know by now that you can use "lookup" to get symbols, but this requires knowing those names. Mhh... I guess that is my shortest so far question xD Thank you in advance for any help! Kind greetings Björn Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr...

...omic<unsigned long>, llvm::MallocAllocator>::try_emplace<int>(llvm::StringRef, int&&) (StringMap.h:322) | | ->03.54% (97,812B) 0x831FD62: llvm::orc::SymbolStringPool::intern(llvm::StringRef) (SymbolStringPool.h:159) | | ->03.54% (97,812B) 0x8320AF5: llvm::orc::ExecutionSession::intern(llvm::StringRef) (Core.h:1225) | | ->03.53% (97,542B) 0x83EFBAE: llvm::orc::MangleAndInterner::operator()(llvm::StringRef) (Mangling.cpp:30) | | | ->03.53% (97,542B) 0x83B20B2: llvm::orc::IRMaterializationUnit::IRMaterializationUnit(llvm::orc::ExecutionSession&,...

...mly crashed due to "corrupted size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession ES; llvm::orc::RTDyldObjectLinkingLayer ObjectLayer(ES, []() { return std::make_unique<llvm::SectionMemoryManager>(); }); auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); auto DL = JTMB->getDefaultDataLayoutForTarget()...

...afeModule 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_ptr<llvm::orc::MaterializationUnit,std::default_delete<llvm::orc::MaterializationUnit>> MU) Line 1218 C++ [External Code] libravi.dll!llvm::orc::ExecutionSession::dispatchMaterialization(llvm::orc::JIT...

...function(s) will happen frequently. One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2) the outright removal of a JITDylib. Right now, I have one ExecutionSession instance for my linker and am creating a new JITDylib for each object file that I'd like to link in. There doesn't appear to be a corresponding ExecutionSession::removeJITDylib(..) method, so I'm wondering: how do I reclaim the memory for code that I've linked in previously but n...

...reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar to KaleidoscopeJIT class with its ExecutionSession, CompileLayer etc.) in my process. Is there an API to reset all memory used? Does deleting the "KaleidoscopeJIT" class ensure all memory is reclaimed? In that case i can periodically re-create that class to achieve what i want. Thanks! Rajesh S R -------------- next part -----------...

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol names we generate >> are unique over time...

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

...way then, how I can lookup the addresses of the Module A, while still having undefined references, but I’m allowed to provide those at a later point? About the multiple LLJIT approach: When I used tryToGenerate for Module A I actually only looked in a hash map of Module B which I filled with their ExecutionSession::lookup function – so tryToGenerate didn’t called that function. However, like I said – a second call to the Module A lookup didn’t triggered another call to tryToGenerate, giving me no chance to ask Module Bs hash map again :c Thank you again ^o^ Kind greetings Björn From: Lang Hames <lha...

...around with it. However, another problem arise which breaks my concept. It is the never ending story of “cross references”. I have again two Modules, which are added to two different LLJIT instances, but they are referencing each other. In the past you suggested me to use the LookUp function of the ExecutionSession to get the addresses – so I wrote this: bool ModuleLoader :: resolve() { auto &ES = this->jit->getExecutionSession(); SymbolLookupSet lookupSet; this->undefinedReferences.clear(); for(const auto &element : this->symbolsOfInterrest) {...

Hey everyone, I felt this question is different from my other question - hope this is okay. So - I was playing around with the lookup function of the ExecutionSession and there are some things I don't understand. I have a .BC file with a function "?Sampler@@YAXXZ" referencing a value "?_Plansch_test@@3HA" that is not defined in that module itself. I first planed on not providing an address for "?_Plansch_test@@3HA" but wanted...

Hey Lang, Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication. My big problem is still handling cross references between modules with “our” name scheme. Since our old loader loads object files, we resolved those references with object files and since they...

...project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 #20 0x00000001062e2844 in llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib&) at /Users/igorgomon/dev/third-party/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:563 #21 0x00000001062db744 in llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib&, std::__1::unique_ptr<llvm::orc::MaterializationUnit, std::__1::default_delete<llvm::orc::MaterializationUnit> >) at /Users/igorgomon/dev/third-party/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:1212 #22 0x00000001062...

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx; But in https://llvm.org/devmtg/2016-11/Slides/Hames-ORC.pdf there is sample code that looks like this: ObjectLinkingLayer LinkLayer; SimpleCompiler Compiler(T...

...>> llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib&) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:563 >>>>> >>>>> #21 0x00000001062db744 in >>>>> llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib&, >>>>> std::__1::unique_ptr<llvm::orc::MaterializationUnit, >>>>> std::__1::default_delete<llvm::orc::MaterializationUnit> >) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/...

Hi Bjoern, Thanks for your patience. The good news is that there is a neater way to do this: ExecutionSession's lookup methods take a orc::SymbolState parameter which describes the state that symbols must reach before a query can return (See https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In your case you want to...

...upid question in this… Kind greetings Björn From: Lang Hames <lhames at gmail.com> Sent: 30 September 2020 19:41 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] ORC JIT - different behaviour of ExecutionSession.lookup? Hi Bjoern, In the current state we don’t have a JIT only an handcrafted object loader. All our object files are pre-compiled but will be loaded by different processes into the same shared memory for the main process to execute them. Ok -- this helps a lot. As a general observation (no...

...:c Thank you again :D Kind greetings Björn From: Lang Hames <lhames at gmail.com> Sent: 29 September 2020 18:55 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] ORC JIT - different behaviour of ExecutionSession.lookup? Hi Bjoern, However, another thing of our system is, that each object file was loaded from a different process, 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...