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

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>

Quick question, using MCJIT/LLVM 3.8:
EngineBuilder has 3 methods:

  EngineBuilder
&setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager>
mcjmm);

  EngineBuilder&
  setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);

  EngineBuilder&
  setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);

IIRC MCJIT uses SectionMemoryManager by default. Can I just provide my
implementation of RuntimeDyld::SymbolResolver or do I have to inherit from
whole SectionMemoryManager?

On Thu, May 12, 2016 at 9:06 PM Paweł Bylica <chfast at gmail.com> wrote:
> 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/20160602/72e4d4a2/attachment.html>

Hi Pawel,

IIRC MCJIT uses SectionMemoryManager by default.


That's right, and it will use that to provide whatever functionality
(memory management or symbol resolution) the user doesn't explicitly
override.

Can I just provide my implementation of RuntimeDyld::SymbolResolver or do
I
> have to inherit from whole SectionMemoryManager?

You can just subclass RuntimeDyld::SymbolResolver and call
setSymbolResolver, and let MCJIT take care of the memory management.

If/when you switch over to ORC you'll need to provide both a symbol
resolver and memory manager with each call to addModuleSet, but for the
memory manager that's usually just a case of calling
llvm::make_unique<SectionMemoryManager>().

- Lang.

On Thu, Jun 2, 2016 at 7:18 AM, Paweł Bylica <chfast at gmail.com> wrote:
> Quick question, using MCJIT/LLVM 3.8:
> EngineBuilder has 3 methods:
>
>   EngineBuilder
> &setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager>
mcjmm);
>
>   EngineBuilder&
>   setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
>
>   EngineBuilder&
>   setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
>
> IIRC MCJIT uses SectionMemoryManager by default. Can I just provide my
> implementation of RuntimeDyld::SymbolResolver or do I have to inherit
> from whole SectionMemoryManager?
>
> On Thu, May 12, 2016 at 9:06 PM Paweł Bylica <chfast at gmail.com>
wrote:
>
>> 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/20160603/4f18ec8b/attachment.html>