llvm dev - Sep 2017 - Some questions regarding ORC JIT apis

Hi,

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.

Thanks and Regards
Dibyendu

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

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 at gmail.com