Yaron Keren
2014-Jul-29 18:07 UTC
[LLVMdev] Reminder: Please switch to MCJIT, as the old JIT will be removed soon.
Hi Keno, Could you give a short high-level overview of the way Julia works now with MCJIT instead the JIT: What I gather so far... * Compiled IR functions are emitted to a shadow module. * Any used function is cloned into its own new module and the module is added to MCJIT. * Called functions or globalvars are only declared in that module. * Modules are never removed meaning "old" functions are abandoned rather then replaced. * All function calls go through a trampoline function doing the multiple dispatch, also enabling old function replacement to new version. Thanks, Yaron 2014-07-25 22:23 GMT+03:00 Keno Fischer <kfischer at college.harvard.edu>:> If you have specific questions about this transition, I might be able > to help out here, as I've gone through this process with Julia (the > process should be a lot smoother now that it's working for a good set > of people, so most bugs should have been found) > > Keno > > On Fri, Jul 25, 2014 at 3:13 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Everyone, > > > > If you're JITing with LLVM and haven't made the switch to MCJIT already, > now > > is the time. As per discussions on the mailing list and at the last dev > > meeting, LLVM 3.5 will be the last release to support the old JIT > > infrastructure. Now that LLVM 3.5 has branched, we plan to start removing > > the old JIT from the mainline. > > > > If you're looking for help in making the switch, Andy Kaylor wrote a > great > > LLVM blog post about porting Kaleidoscope to MCJIT, which you can find at > > http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html > . > > I'll also be working to update the LLVM docs and the Kaleidoscope > tutorial, > > and as always you can ask for help in the mailing lists and on IRC. > > > > Good luck with the switch over! > > > > Cheers, > > Lang. > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > 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/20140729/83e9cd88/attachment.html>
Keno Fischer
2014-Aug-07 23:33 UTC
[LLVMdev] Reminder: Please switch to MCJIT, as the old JIT will be removed soon.
I feel really bad for answering this sooner. I had a draft email but for some reason never sent it out (though I had). My apologies.> * Compiled IR functions are emitted to a shadow module.Julia has two different modes of compilation. In one we do the shadow module thing and whenever we need to call something that's not been pulled out yet, we compile it and the closure of it's callgraph and pull it out into a separate module, because we later dump the shadow module as a whole and compile it as a shared library for caching generated code. In the other we create a module per function and just emit it into the module directly (because we don't want to keep around the bitcode if we're not going to use it, so we delete it right aftre). Eventually I'm going to have to reevaluate this, because one module per function is slightly expensive (though not as bad now as it used to be because of some changes in MCJIT).> * Any used function is cloned into its own new module and the module is added to MCJIT.Basically correct Correct, when the shadow module exists, yes.> * Called functions or globalvars are only declared in that module.I'm not sure what you mean by that. When generating the code (or copying it), we declare all used global in the module.> * Modules are never removed meaning "old" functions are abandoned rather then replaced. > * All function calls go through a trampoline function doing the multiple dispatch, also enabling old function replacement to new version.Correct, though this is actually a long standing issue we have where we are not correctly replacing functions if they are sufficiently optimized (so that we don't go through the trampoline). I'm hoping to address this soon using patchpoints, but haven't gotten to that yet. For now what people who want to replace functions basically do is replace the bindings in the repl which will force the old code to be abandoned. Hope that helps and sorry for forgetting to send this out, please do send further questions and I'll promise I'll respond more swiftly. Keno On Tue, Jul 29, 2014 at 2:07 PM, Yaron Keren <yaron.keren at gmail.com> wrote:> Hi Keno, > > Could you give a short high-level overview of the way Julia works now with > MCJIT instead the JIT: > > What I gather so far... > > * Compiled IR functions are emitted to a shadow module. > * Any used function is cloned into its own new module and the module is > added to MCJIT. > * Called functions or globalvars are only declared in that module. > * Modules are never removed meaning "old" functions are abandoned rather > then replaced. > * All function calls go through a trampoline function doing the multiple > dispatch, also enabling old function replacement to new version. > > Thanks, > > Yaron > > > > > 2014-07-25 22:23 GMT+03:00 Keno Fischer <kfischer at college.harvard.edu>: >> >> If you have specific questions about this transition, I might be able >> to help out here, as I've gone through this process with Julia (the >> process should be a lot smoother now that it's working for a good set >> of people, so most bugs should have been found) >> >> Keno >> >> On Fri, Jul 25, 2014 at 3:13 PM, Lang Hames <lhames at gmail.com> wrote: >> > Hi Everyone, >> > >> > If you're JITing with LLVM and haven't made the switch to MCJIT already, >> > now >> > is the time. As per discussions on the mailing list and at the last dev >> > meeting, LLVM 3.5 will be the last release to support the old JIT >> > infrastructure. Now that LLVM 3.5 has branched, we plan to start >> > removing >> > the old JIT from the mainline. >> > >> > If you're looking for help in making the switch, Andy Kaylor wrote a >> > great >> > LLVM blog post about porting Kaleidoscope to MCJIT, which you can find >> > at >> > >> > http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html. >> > I'll also be working to update the LLVM docs and the Kaleidoscope >> > tutorial, >> > and as always you can ask for help in the mailing lists and on IRC. >> > >> > Good luck with the switch over! >> > >> > Cheers, >> > Lang. >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Yaron Keren
2014-Aug-08 17:41 UTC
[LLVMdev] Reminder: Please switch to MCJIT, as the old JIT will be removed soon.
Thanks! 2014-08-08 2:33 GMT+03:00 Keno Fischer <kfischer at college.harvard.edu>:> I feel really bad for answering this sooner. I had a draft email but > for some reason never sent it out (though I had). My apologies. > > > * Compiled IR functions are emitted to a shadow module. > Julia has two different modes of compilation. In one we do the shadow > module thing and whenever we need to call something that's not been > pulled out yet, we compile it and the closure of it's callgraph and > pull it out into a separate module, because we later dump the shadow > module as a whole and compile it as a shared library for caching > generated code. In the other we create a module per function and just > emit it into the module directly (because we don't want to keep around > the bitcode if we're not going to use it, so we delete it right > aftre). Eventually I'm going to have to reevaluate this, because one > module per function is slightly expensive (though not as bad now as it > used to be because of some changes in MCJIT). > > > * Any used function is cloned into its own new module and the module is > added to MCJIT. > Basically correct > Correct, when the shadow module exists, yes. > > > * Called functions or globalvars are only declared in that module. > I'm not sure what you mean by that. When generating the code (or > copying it), we declare all used global in the module. > > > * Modules are never removed meaning "old" functions are abandoned rather > then replaced. > > * All function calls go through a trampoline function doing the multiple > dispatch, also enabling old function replacement to new version. > > Correct, though this is actually a long standing issue we have where > we are not correctly replacing functions if they are sufficiently > optimized (so that we don't go through the trampoline). I'm hoping to > address this soon using patchpoints, but haven't gotten to that yet. > > For now what people who want to replace functions basically do is > replace the bindings in the repl which will force the old code to be > abandoned. > > Hope that helps and sorry for forgetting to send this out, please do > send further questions and I'll promise I'll respond more swiftly. > > > Keno > > On Tue, Jul 29, 2014 at 2:07 PM, Yaron Keren <yaron.keren at gmail.com> > wrote: > > Hi Keno, > > > > Could you give a short high-level overview of the way Julia works now > with > > MCJIT instead the JIT: > > > > What I gather so far... > > > > * Compiled IR functions are emitted to a shadow module. > > * Any used function is cloned into its own new module and the module is > > added to MCJIT. > > * Called functions or globalvars are only declared in that module. > > * Modules are never removed meaning "old" functions are abandoned rather > > then replaced. > > * All function calls go through a trampoline function doing the multiple > > dispatch, also enabling old function replacement to new version. > > > > Thanks, > > > > Yaron > > > > > > > > > > 2014-07-25 22:23 GMT+03:00 Keno Fischer <kfischer at college.harvard.edu>: > >> > >> If you have specific questions about this transition, I might be able > >> to help out here, as I've gone through this process with Julia (the > >> process should be a lot smoother now that it's working for a good set > >> of people, so most bugs should have been found) > >> > >> Keno > >> > >> On Fri, Jul 25, 2014 at 3:13 PM, Lang Hames <lhames at gmail.com> wrote: > >> > Hi Everyone, > >> > > >> > If you're JITing with LLVM and haven't made the switch to MCJIT > already, > >> > now > >> > is the time. As per discussions on the mailing list and at the last > dev > >> > meeting, LLVM 3.5 will be the last release to support the old JIT > >> > infrastructure. Now that LLVM 3.5 has branched, we plan to start > >> > removing > >> > the old JIT from the mainline. > >> > > >> > If you're looking for help in making the switch, Andy Kaylor wrote a > >> > great > >> > LLVM blog post about porting Kaleidoscope to MCJIT, which you can find > >> > at > >> > > >> > > http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html. > >> > I'll also be working to update the LLVM docs and the Kaleidoscope > >> > tutorial, > >> > and as always you can ask for help in the mailing lists and on IRC. > >> > > >> > Good luck with the switch over! > >> > > >> > Cheers, > >> > Lang. > >> > > >> > > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > >> _______________________________________________ > >> 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/20140808/eba5ea13/attachment.html>