Lang Hames
2015-Feb-10 22:28 UTC
[LLVMdev] Some basic questions regarding MCJIT and Kaleidoscope sample
HI Dibyendu, A single MCJIT instance can notionally manage multiple modules, but there are caveats (which I'm afraid I don't remember off the top of my head) that make it unattractive in practice. I believe most clients opt for something like the ExecutionEngine-per-Module model used in the Kaleidoscope tutorials. As Dave mentioned, I'm also working on some new JIT APIs (Orc) that are intended to be more feature-rich and easier to use than MCJIT. If you would like to try them out and have any questions about how they work please don't hesitate to ask. You'll need to live on the bleeding edge for those though - they're not available on 3.5. Cheers, Lang. On Tue, Feb 10, 2015 at 2:14 PM, David Blaikie <dblaikie at gmail.com> wrote:> We (and by 'we' I mean 'Lang' (cc'd)) have recently been experimenting > with improvements/replacements to the MCJIT in the form of Orc, a new > layered, composable JIT API. There are examples of this in the Kaleidoscope > code samples (llvm/examples/Kaleidoscope/Orc) though not comprehensive > tutorials as yet. > > On Tue, Feb 10, 2015 at 1:57 PM, Dibyendu Majumdar <mobile at majumdar.org.uk > > wrote: > >> Hi, >> >> I am building a new JIT compiler for Lua (actually a derivative of >> Lua), and am planning to use LLVM for this. I have trying out some >> basic functions using LLVM 3.5.1. I have been puzzled by one aspect of >> the MCJIT versions of the Kaleidoscope sample, and would hugely >> appreciate some insight. >> >> Can a single MCJIT instance be used to manage several modules? >> Why is a separate MCJIT instance created for each module? >> >> Unfortunately the tutorial text does not explain the rationale for this. >> >> At the moment in my implementation I am putting each compiled function >> in its own module and creating an engine for it. This is so that each >> function can be managed independently and linked to garbage collection >> in Lua. However I do not know if there is a better way - for example >> creating a shared engine across all modules. I would also like to >> understand the trade offs with this approach versus other approaches. >> >> Many thanks >> >> Regards >> Dibyendu >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150210/ee918f96/attachment.html>
Dibyendu Majumdar
2015-Feb-10 22:46 UTC
[LLVMdev] Some basic questions regarding MCJIT and Kaleidoscope sample
Hi James, On 10 February 2015 at 22:28, Lang Hames wrote:> > A single MCJIT instance can notionally manage multiple modules, but there > are caveats (which I'm afraid I don't remember off the top of my head) that > make it unattractive in practice. I believe most clients opt for something > like the ExecutionEngine-per-Module model used in the Kaleidoscope > tutorials.I see. That's good to know.> As Dave mentioned, I'm also working on some new JIT APIs (Orc) that are > intended to be more feature-rich and easier to use than MCJIT. If you would > like to try them out and have any questions about how they work please don't > hesitate to ask. You'll need to live on the bleeding edge for those though - > they're not available on 3.5. >I am at an early stage of development so I can use Orc provided there is some assurance that this will be mainstream in future. Else I can use the MCJIT replacement that uses Orc. If I wanted to do this should I clone the latest code from github? In any case I am abstracting the creation and management of engines, modules etc in my code so that I can change this in future if necessary. Thanks and Regards Dibyendu
Dibyendu Majumdar
2015-Feb-10 23:15 UTC
[LLVMdev] Some basic questions regarding MCJIT and Kaleidoscope sample
Hi Lang, Sincere apologies for the name typo below! Regards On 10 February 2015 at 22:46, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> Hi James, > > On 10 February 2015 at 22:28, Lang Hames wrote: >> >> A single MCJIT instance can notionally manage multiple modules, but there >> are caveats (which I'm afraid I don't remember off the top of my head) that >> make it unattractive in practice. I believe most clients opt for something >> like the ExecutionEngine-per-Module model used in the Kaleidoscope >> tutorials. > > I see. That's good to know. > >> As Dave mentioned, I'm also working on some new JIT APIs (Orc) that are >> intended to be more feature-rich and easier to use than MCJIT. If you would >> like to try them out and have any questions about how they work please don't >> hesitate to ask. You'll need to live on the bleeding edge for those though - >> they're not available on 3.5. >> > > I am at an early stage of development so I can use Orc provided there > is some assurance that this will be mainstream in future. Else I can > use the MCJIT replacement that uses Orc. If I wanted to do this should > I clone the latest code from github? > > In any case I am abstracting the creation and management of engines, > modules etc in my code so that I can change this in future if > necessary. > > Thanks and Regards > > Dibyendu