search for: ownedmodules

...lists.llvm.org> wrote: > Actually, looking at the destructors for LLVMContext and Module I do not > think the current ownership scheme makes sense, so this might be a good > opportunity to 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 dele...

..., looking at the destructors for LLVMContext and Module I do not >>> think the current ownership scheme makes sense, so this might be a good >>> opportunity to 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); >>> ... >>> >>> LLVMC...

...function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded". Am I right? Regards. rodia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/bdea2e51/attachment.html&...

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

...and linking, but the actual destination module only has 393MB of MDNodes. There are 649-393MB (40% of 649MB) not used. MDNodes belong to the Context, deleting modules will not release the MDNodes. One possible solution is: In LLVMContext, add “removeUnusedMDNodes" function It goes through OwnedModules and check if a MDNode is used by any of the modules, if not remove it. One implementation is to mark a visited MDNode used when traversing the module. After done traversing all modules, we can delete MDNodes in MDNodeSet that are not marked. In LTOCodeGenerator, add a vector of source modules th...

...at machine code for second "owned" module will never be generated if it >> doesn't depend on the first one. More over it will cause a crash if entry >> point isn't in first module. Implementation of finalizeObject using for >> loop will omit every other module in OwnedModules, because function >> generateCodeForModule moves module form "added" to "loaded". >> Am I right? >> >> Regards. >> >> rodia >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMde...

...dule only has 393MB of MDNodes. There are 649-393MB (40% of > 649MB) not used. > > MDNodes belong to the Context, deleting modules will not release the > MDNodes. > > One possible solution is: > > In LLVMContext, add “removeUnusedMDNodes" function > It goes through OwnedModules and check if a MDNode is used by any of the > modules, if not remove it. > One implementation is to mark a visited MDNode used when traversing the > module. After done traversing all modules, we can delete MDNodes in > MDNodeSet that are not marked. > > In LTOCodeGenerator, add...

...e are 649-393MB (40% of >> 649MB) not used. >> >> MDNodes belong to the Context, deleting modules will not release the >> MDNodes. >> >> One possible solution is: >> >> In LLVMContext, add “removeUnusedMDNodes" function >> It goes through OwnedModules and check if a MDNode is used by any of >> the modules, if not remove it. >> One implementation is to mark a visited MDNode used when traversing the >> module. After done traversing all modules, we can delete MDNodes in >> MDNodeSet that are not marked. >> >> I...

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet 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....

...649MB) not used. >>> >>> MDNodes belong to the Context, deleting modules will not release the >>> MDNodes. >>> >>> One possible solution is: >>> >>> In LLVMContext, add “removeUnusedMDNodes" function >>> It goes through OwnedModules and check if a MDNode is used by any of >>> the modules, if not remove it. >>> One implementation is to mark a visited MDNode used when traversing >>> the module. After done traversing all modules, we can delete MDNodes in >>> MDNodeSet that are not marked. &gt...

...at gmail.com] Sent: Monday, October 21, 2013 10:57 PM To: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew Subject: SmallPtrSet patch for MCJIT Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet 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....

...;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 second ParseBitCodeFile, StructType::setName will introduce struct.cmd0 due to conflict. should we do thorough cleanup for the...

...* > > ** ** > > Hi Andy,**** > > ** ** > > Here is the patch. it incorporates:**** > > ** ** > > 1) your latest patch to SVN.**** > > 2) mcjit-module-state-optimization.patch.**** > > 3) the PtrSet 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 addModu...

...t; >>>> MDNodes belong to the Context, deleting modules will not release the >>>> MDNodes. >>>> >>>> One possible solution is: >>>> >>>> In LLVMContext, add “removeUnusedMDNodes" function >>>> It goes through OwnedModules and check if a MDNode is used by any of >>>> the modules, if not remove it. >>>> One implementation is to mark a visited MDNode used when traversing >>>> the module. After done traversing all modules, we can delete MDNodes in >>>> MDNodeSet that are...