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