llvm dev - Aug 2016 - Rationale for the object cache design?

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160818/28868bfd/attachment.html>

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/955c1f41/attachment.html>