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,

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
(2016 LLVM Developers’ Meeting: L. Hames “ORC -- LLVM's Next Generation of JIT API” - YouTube).

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

Hi Stefan,