llvm dev - May 2016 - Orc/MCJIT: Relocations vs pointers to functions

Hi LLVM, Lang.

I'm looking for a advice here. And I truly understand very little what the
relocations are and how they work.

The problem I want to solve is the case where a jitted code has to call
back the host application to query additional data. I can think of 3
possible solutions:

   1. Use built-in relocation resolver (in default memory manager?) and
   allow the JIT to find the callback function by name. The host application
   needs to contain symbols that the JIT will search for. You can have only
   single implementation of them. The JIT will need to search in the set of
   all symbols in the executable.
   2. Pass addresses of callback functions as pointers to functions to a
   jitted function. The generated code should use pointer to functions instead
   of predefined function names in calls.
   3. Create you own Memory Manager that will provide addresses to callback
   functions. Because the set of callback functions is known upfront and quite
   small that seems to be better than 1.

Can you help me to evaluate the solutions?

- Paweł
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160511/6b819ae4/attachment.html>

Hi Pawel,

Option (1) and (3) are very similar, but using custom resolution (option 3)
guarantees that JIT'd code can't accidentally end up depending on
functions
in your JIT that you didn't mean to expose. Having a smaller symbol lookup
space may improve performance too.
Option (2) would work, but there's no advantage vs option (3).

So I recommend option 3. :)

If you're using MCJIT you can override the findSymbol method on the
MemoryManager. If you're using ORC you can pass a custom resolver to
addModuleSet.

Cheers,
Lang.


On Wed, May 11, 2016 at 6:47 AM, Paweł Bylica <chfast at gmail.com> wrote:
> Hi LLVM, Lang.
>
> I'm looking for a advice here. And I truly understand very little what
the
> relocations are and how they work.
>
> The problem I want to solve is the case where a jitted code has to call
> back the host application to query additional data. I can think of 3
> possible solutions:
>
>    1. Use built-in relocation resolver (in default memory manager?) and
>    allow the JIT to find the callback function by name. The host
application
>    needs to contain symbols that the JIT will search for. You can have only
>    single implementation of them. The JIT will need to search in the set of
>    all symbols in the executable.
>    2. Pass addresses of callback functions as pointers to functions to a
>    jitted function. The generated code should use pointer to functions
instead
>    of predefined function names in calls.
>    3. Create you own Memory Manager that will provide addresses to
>    callback functions. Because the set of callback functions is known
upfront
>    and quite small that seems to be better than 1.
>
> Can you help me to evaluate the solutions?
>
> - Paweł
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/20c91453/attachment.html>

Thanks!

Currently using MCJIT. But migration to ORC is on my TODO list.

- Paweł

On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote:
> Hi Pawel,
>
> Option (1) and (3) are very similar, but using custom resolution (option
> 3) guarantees that JIT'd code can't accidentally end up depending
on
> functions in your JIT that you didn't mean to expose. Having a smaller
> symbol lookup space may improve performance too.
> Option (2) would work, but there's no advantage vs option (3).
>
> So I recommend option 3. :)
>
> If you're using MCJIT you can override the findSymbol method on the
> MemoryManager. If you're using ORC you can pass a custom resolver to
> addModuleSet.
>
> Cheers,
> Lang.
>
>
> On Wed, May 11, 2016 at 6:47 AM, Paweł Bylica <chfast at gmail.com>
wrote:
>
>> Hi LLVM, Lang.
>>
>> I'm looking for a advice here. And I truly understand very little
what
>> the relocations are and how they work.
>>
>> The problem I want to solve is the case where a jitted code has to call
>> back the host application to query additional data. I can think of 3
>> possible solutions:
>>
>>    1. Use built-in relocation resolver (in default memory manager?) and
>>    allow the JIT to find the callback function by name. The host
application
>>    needs to contain symbols that the JIT will search for. You can have
only
>>    single implementation of them. The JIT will need to search in the
set of
>>    all symbols in the executable.
>>    2. Pass addresses of callback functions as pointers to functions to
a
>>    jitted function. The generated code should use pointer to functions
instead
>>    of predefined function names in calls.
>>    3. Create you own Memory Manager that will provide addresses to
>>    callback functions. Because the set of callback functions is known
upfront
>>    and quite small that seems to be better than 1.
>>
>> Can you help me to evaluate the solutions?
>>
>> - Paweł
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/38eeeab0/attachment.html>