search for: removemodul

I'm on llvm 3.8.1 and was wondering if there's a memory leak in the removeModule impl of mcjit. In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html a module is removed from the Jit by invoking removeModule. According to the tutorial: "Its API is very simple:: addModule adds an LLVM IR module to the JIT, making its functions available for executio...

...(llvm::ParseBitcodeFile(buffer, llvmCtx, &ErrMsg)); module->dump(); } { llvm::OwningPtr<llvm::Module> module(llvm::ParseBitcodeFile(buffer, llvmCtx, &ErrMsg)); module->dump(); } } with smart pointer, the 1st module will be deleted and call removeModule for the context. The implementation of removeModule is quite simple. It just removes the PtrSet. pImpl->OwnedModules.erase(M); It doesn't touch LLVMContextImpl's NamedStructTypes. As a result, 'struct.cmd' is still in the symbol table even the module has destroyed. In secon...

...was a valid VModuleKey in ORCv1. The assertion is checking the the VModuleKey is present in the LogicalDylibs map. That means that you have to have used that key in an addModule call, e.g.: > > CODLayer.addModule(K, std::move(M)); > > and not subsequently removed the key with a call to removeModule. Yes indeed that is what happened. So to prevent that I need to check if VModuleKey was ever initialized ... how do I do that? I would have to have to add another flag to track the initialized state. The reason for it not being initialized is that sometimes I cannot generate JIT code because some...

Hi, I am getting following assertion failure when attempting to remove a module. /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT = llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>, std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >; CompileCal...

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is dead/deprecated and projects using it should start > migrating aw...

...:ExecutionEngine. But now I started to wonder, if I could reuse that instance for a new module again? I first tried calling llvm::EngineBuilder without setting a Module, I planned to add it later - but when I do this the "create" function will crash. Another test I ran was calling "removeModule" of the llvm::ExecutionEngine after the call to finalizeObject. Then I added the same module again and ran finalizeObject again. The result was weird, I suddenly became error messages about the relocation - I take this came because I applied a memory mapping in the first run. So to make it...

...noticed: [https://media.discordapp.net/attachments/534012750045642783/575369402195640321/unknown.png] This code will crash when calling "eeBuilder.create". But I also looked at what happens if I do reuse the llvm::ExecutionEngine. After the call to "finalizeObject" I use "removeModule" for the Module I used. If I know parse the same module again and pass it to that llvm::ExecutionEngine, it will notice the duplication and rename the symbols, like when it does when you add the same module two times. If I add a different module everything behaves as before - so overall it se...

...t holds many modules created later, as needed. Workaround for current API could be 1) using a pointer to EE init with NULL, delaying the actual EE construction to the time the first module is ready and skipping construction with later modules. or 2) supplying a dummy Module to the creator and then removeModule(M). Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131017/fb098fd2/attachment.html>

...re-think it. > > Right now an LLVMContext owns a list of modules (see > LLVMContextImpl::OwnedModules) that it destroys when its destructor is > called. Modules remove themselves from this list if they are destructed > before the context: > > Module::~Module() { > Context.removeModule(this); > ... > > LLVMContextImpl::~LLVMContextImpl() { > // NOTE: We need to delete the contents of OwnedModules, but Module's > dtor > // will call LLVMContextImpl::removeModule, thus invalidating iterators > into > // the container. Avoid iterators during this...

Hi, You cannot call removeModule on a JIT with no modules: jitstate will be 0 and therefore we have a null-pointer exception. The function returns a boolean for success/failure, however, so you would expect to be able to call it and get false back. Should we be checking for jitstate != 0 before accessing the variable? - if (...

...t holds many modules created later, as needed. Workaround for current API could be 1) using a pointer to EE init with NULL, delaying the actual EE construction to the time the first module is ready and skipping construction with later modules. or 2) supplying a dummy Module to the creator and then removeModule(M). Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131017/4401e80b/attachment.html>

...want to do. I need to retain the machine code indefinitely, but I want to free all possible other resources that are not strictly needed simply to jump into the machine code and execute it. In particular, the Modules appear to be the culprit in the memory consumption. If I call ExecutionEngine::removeModule (after JITing a function from the module), does that mean that I can subsequently no longer call the function? Or can I? Can I delete the Module at that point and still use the machine code? -- Larry Gritz lg at larrygritz.com

...owns a list of modules (see >>> LLVMContextImpl::OwnedModules) that it destroys when its destructor is >>> called. Modules remove themselves from this list if they are destructed >>> before the context: >>> >>> Module::~Module() { >>> Context.removeModule(this); >>> ... >>> >>> LLVMContextImpl::~LLVMContextImpl() { >>> // NOTE: We need to delete the contents of OwnedModules, but Module's >>> dtor >>> // will call LLVMContextImpl::removeModule, thus invalidating >>> iterators i...

...trSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT overridden addModule but not removeModule so the EE version was called. Second, both MCJIT and EE constructors take ownership of the module and their destructors try to delete it. Fixed this with a hack in MCJIT destructor and a FIXME comment, the real fix is simply getting EE out of the picture. It just interferes. I know it's in the...

...utionEngines depends on your use case, but for non-trivial use-cases yes: One ExecutionEngine per Module seems to be required. 2. When I add a module and jit it, can I invoke a remove module and still > be able to execute the compiled function? You can remove the module using ExecutionEngine::removeModule(M), but be aware that this will clear the global mappings associated with the Module, so any interfaces that use IR will no longer function. 3. Is it better to have one runtime mem manager that will be associated > with multiple execution engines (one engine per module)? Using this > approa...

...yCompilation(); After passing in the compiled module, I call: EE->runStaticConstructorsDestructors(module, false); Then to test the tear-down of the module, I call: EE->runStaticConstructorsDestructors(mImpl->module, true); EE->clearGlobalMappingsFromModule(mImpl->module); EE->removeModule(mImpl->module); The C++ code compiled: #include <stdio.h> class Foo { public: Foo() { printf("Foo\n"); }; ~Foo() { printf("~Foo\n"); }; int x; }; // a static variable: Foo foo; The constructor is being called (I see 'Foo' in my stdout), but the des...

...llvm::SmallPtrSetImplBase::erase_imp (this=0x0, Ptr=0x68c200) at /opt/llvm/lib/Support/SmallPtrSet.cpp:78 #2 0x00007ffff14c9174 in llvm::SmallPtrSetImpl<llvm::Module*>::erase (this=0x0, Ptr=0x68c200) at /opt/llvm/include/llvm/ADT/SmallPtrSet.h:275 #3 0x00007ffff14c81cb in llvm::LLVMContext::removeModule (this=0x691910, M=0x68c200) at /opt/llvm/lib/IR/LLVMContext.cpp:148 #4 0x00007ffff1527b7b in llvm::Module::~Module (this=0x68c200, __in_chrg=<optimised out>) at /opt/llvm/lib/IR/Module.cpp:57 #5 0x00007ffff70f9511 in std::default_delete<llvm::Module>::operator() (this=<optimised o...

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi All, ORC's new concurrent compilation model generates some interesting lifetime and thread safety questions around LLVMContext: We need multiple LLVMContexts (one per module in the simplest case, but at least one per thread), and the lifetime of each context depends on the execution path of the JIT'd code. We would like to deallocate contexts once all modules associated with them have

...trSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT overridden addModule but not removeModule so the EE version was called. Second, both MCJIT and EE constructors take ownership of the module and their destructors try to delete it. Fixed this with a hack in MCJIT destructor and a FIXME comment, the real fix is simply getting EE out of the picture. It just interferes. I know it's in the...