[llvm-dev] Rationale for the object cache design?

[Lang Hames via llvm-dev]

Hi Antoine,

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.

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<>.

The ObjectLinkingLayer API can be found at:
http://llvm.org/doxygen/classllvm_1_1orc_1_1ObjectLinkingLayer.html

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.

Cheers,
Lang.

On Mon, Aug 22, 2016 at 1:22 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Antoine,
>
> The ObjectCache-as-callback design is a result of MCJIT's black-box design.
>
> 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.
>
> See http://llvm.org/docs/tutorial/BuildingAJIT1.html 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.
>
> Cheers,
> Lang.
>
> On Thu, Aug 18, 2016 at 12:21 PM, Paweł Bylica <llvm-dev at lists.llvm.org>
> wrote:
>
>> 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.
>>
>> Maybe the ObjectCache should allow using arbitrary cache key, not forcing
>> the module to be also the key.
>>
>> On Thu, Aug 13, 2015 at 7:52 PM Antoine Pitrou via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>> Hello,
>>>
>>> I am a bit curious about the rationale for the current callback-based
>>> object cache API.  For Numba, it would be easier if there would be a
>>> simple procedural API:
>>> - one method to get a module's compiled object code
>>> - one method to load/instantiate a module from a given piece of object
>>> code
>>>
>>> I manage to get around the callback-based API to do what I want, but
>>> it's a bit weird to work with.  Would the above API suggestions be a
>>> desirable addition?
>>>
>>> PS: the gmane mirror for this list doesn't seem migrated yet, so I'm not
>>> sure this message will reach the list...
>>>
>>> Regards
>>>
>>> Antoine.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160822/ecca9415/attachment.html>