<div dir="ltr">Hi Antoine,<div><br></div><div>The ObjectCache-as-callback design is a result of MCJIT's black-box design.</div><div><br></div><div>I would recommend checking out the ORC (include/llvm/ExecutionEngine/Orc) JIT APIs. Rather than being given a black box like MCJIT, you build your own JIT class from the ORC components. This allows you to use the kind of procedural design you described.</div><div><br></div><div>See <a href="http://llvm.org/docs/tutorial/BuildingAJIT1.html">http://llvm.org/docs/tutorial/BuildingAJIT1.html</a> for a tutorial (still under development) that shows you how to build a simple JIT from ORC components. The demo code from the first chapter should be enough to get you up and running.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 18, 2016 at 12:21 PM, Paweł Bylica <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have the issue with the current ObjectCache API as well. I would like to cache also the generation of IR modules from frontend code. I am able to check if the cached object exists, but I still need to create a fake (but valid) IR module and pass it to MCJIT. The MCJIT will then ask the ObjectCache again to load the object.<div><br></div><div>Maybe the ObjectCache should allow using arbitrary cache key, not forcing the module to be also the key.</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 13, 2015 at 7:52 PM Antoine Pitrou via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello,<br>
<br>
I am a bit curious about the rationale for the current callback-based<br>
object cache API.  For Numba, it would be easier if there would be a<br>
simple procedural API:<br>
- one method to get a module's compiled object code<br>
- one method to load/instantiate a module from a given piece of object code<br>
<br>
I manage to get around the callback-based API to do what I want, but<br>
it's a bit weird to work with.  Would the above API suggestions be a<br>
desirable addition?<br>
<br>
PS: the gmane mirror for this list doesn't seem migrated yet, so I'm not<br>
sure this message will reach the list...<br>
<br>
Regards<br>
<br>
Antoine.<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>