[llvm-dev] Some questions regarding ORC JIT apis

[Stefan Gränitz via llvm-dev]

Hi Dibyendu

> On Windows 10 64-bit, with
> dynamic linking - I found one unexpected behaviour - the findSymbol()
> is unable to locate the JIT compiled function in the module if search
> for "exported" only is true ... even though the function is defined as
> having ExternalLinkage. I have to test on Linux / Mac OSX to see if
> the behaviour is different there.
Correct. There's a comment on it in the Kaleidoscope example:
https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/include/KaleidoscopeJIT.h#L93

Cheers
Stefan

Am 24.09.17 um 00:36 schrieb Dibyendu Majumdar via llvm-dev:
> Hi,
>
> On 22 September 2017 at 15:33, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:
>> I am looking to port my MCJIT based implementation to ORC. I have been
>> reading up on the ORC tutorials, but am not clear on how to do
>> following:
>>
>> I would like to discard everything other than the compiled code after
>> compiling a module.
>> A module may have more than one function in it - so I would like to
>> retain all the compiled functions.
>> I am okay with eager compilation - i.e. there is no need to hold on to
>> a module for lazy compilation.
>> Finally at some later point I would like to able to delete functions
>> that are no longer needed.
>>
>> If there is an example of above then that would be great.
>>
>> Currently in MCJIT I keep the Module/ExecutionEngine around until the
>> functions in them are no longer needed. This is very bad for memory as
>> all that IR just hangs around.
>>
> I found following note from the archives:
>
> <quote>
>> @Lang, would it be possible for one of the kaleidoscope tutorials to demonstrate how to hook up freeing the Module/Context but still run any binary bits?
> The new ORC-based Kaleidoscope tutorials are actually already doing
> this. You get this behavior more-or-less for free if you use the ORC
> JIT APIs, because of an interplay between two features:
>
> (1) All the ORC components try to destroy their module and object-file
> pointers as soon as they can, and
> (2) The module and object pointer types are template types.
>
> So, if you pass your Modules in as 'unique_ptr<Module>'s, the JIT will
> delete them as soon as its done with them, freeing the memory in the
> process.
> The executable code for the JIT is owned by the user's memory manager
> which is managed using a similar scheme except that the memory manager
> pointer lives until the JIT is torn down, or the user explicitly asks
> the JIT to discard it.
> <endquote>
>
> Also additional information from watching the talk by Lang
> (https://www.youtube.com/watch?v=hILdR8XRvdQ).
>
> So it seems that ORC apis essentially give me what I am looking for.
>
> I managed to port my code easily enough. On Windows 10 64-bit, with
> dynamic linking - I found one unexpected behaviour - the findSymbol()
> is unable to locate the JIT compiled function in the module if search
> for "exported" only is true ... even though the function is defined as
> having ExternalLinkage. I have to test on Linux / Mac OSX to see if
> the behaviour is different there.
>
> Regards
> Dibyendu
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graenitz@gmail.com