<div dir="ltr">Hi Antoine,<div><br></div><div>Actually, I misremembered where the tutorial series started: The code for the first chapter is already using the IRCompileLayer which manages compilation (and caches) for you.</div><div><br></div><div>I think what you want is just a class with ObjectLinkingLayer<> and a SimpleCompiler: When someone tries to add an IR file you can perform whatever cache lookup you like and then either take the object from the cache, or call the SimpleCompiler to compile the object from IR, then add the object to the ObjectLinkingLayer<>.</div><div><br></div><div>The ObjectLinkingLayer API can be found at: <a href="http://llvm.org/doxygen/classllvm_1_1orc_1_1ObjectLinkingLayer.html">http://llvm.org/doxygen/classllvm_1_1orc_1_1ObjectLinkingLayer.html</a></div><div><br></div><div>Your class will probably end up looking like a simplified version of IRCompileLayer (include/llvm/ExecutionEngine/Orc/IRCompileLayer), with your cache lookup substituted for the current calls to the ObjectCache. </div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 1:22 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</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">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/<wbr>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" target="_blank">http://llvm.org/docs/<wbr>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"><div><div class="h5">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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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><div><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" target="_blank">llvm-dev@lists.llvm.org</a><br>
</div></div><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>
</blockquote></div><br></div>