[llvm-dev] Orc/MCJIT: Relocations vs pointers to functions

[Paweł Bylica via llvm-dev]

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>