Yaron Keren
2013-Oct-17 19:46 UTC
[LLVMdev] ExecutionEngine should have a non-Module creator
With the support of Multi-modules, it makes sense to have a creator / constructor for ExecutionEngine that does not require a module. The use-case is a program using one EE created at initialization that 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>
Kaylor, Andrew
2013-Oct-17 19:57 UTC
[LLVMdev] ExecutionEngine should have a non-Module creator
I agree that this would be useful. One minor stumbling block is that the EngineBuilder uses the supplied Module to determine the target triple when creating the TargetMachine. Obviously that could be handled with different EngineBuilder usage (the API may even already be there for that). It's just something to consider. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Thursday, October 17, 2013 12:46 PM To: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew Subject: ExecutionEngine should have a non-Module creator With the support of Multi-modules, it makes sense to have a creator / constructor for ExecutionEngine that does not require a module. The use-case is a program using one EE created at initialization that 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>
Yaron Keren
2013-Oct-17 21:28 UTC
[LLVMdev] ExecutionEngine should have a non-Module creator
If someone encounters this problem here is my workaround code, globals: llvm::OwningPtr<llvm::ExecutionEngine> m_EE; llvm::Module* m_LastModule; after making module: if (!m_EE) { m_EE.reset(llvm::EngineBuilder(m_LastModule) .setErrorStr(&Error) .setUseMCJIT(true) .create()); } else { m_EE->addModule(m_LastModule); } Yaron 2013/10/17 Kaylor, Andrew <andrew.kaylor at intel.com>> I agree that this would be useful. One minor stumbling block is that > the EngineBuilder uses the supplied Module to determine the target triple > when creating the TargetMachine. Obviously that could be handled with > different EngineBuilder usage (the API may even already be there for > that). It’s just something to consider.**** > > ** ** > > -Andy**** > > ** ** > > *From:* Yaron Keren [mailto:yaron.keren at gmail.com] > *Sent:* Thursday, October 17, 2013 12:46 PM > *To:* <llvmdev at cs.uiuc.edu>; Kaylor, Andrew > *Subject:* ExecutionEngine should have a non-Module creator**** > > ** ** > > With the support of Multi-modules, it makes sense to have a creator / > constructor for ExecutionEngine that does not require a module.**** > > ** ** > > The use-case is a program using one EE created at initialization that > 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/20131018/6fccc7aa/attachment.html>
Apparently Analagous Threads
- [LLVMdev] ExecutionEngine should have a non-Module creator
- [LLVMdev] Set up ExecutionEngine according to actual machine capabilities
- [LLVMdev] SmallPtrSet patch for MCJIT
- [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
- [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?