[llvm-dev] Some questions regarding ORC JIT apis

[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