[llvm-dev] Some questions regarding ORC JIT apis (original) (raw)

Dibyendu Majumdar via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 23 15:36:20 PDT 2017

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:

> _@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'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.

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

More information about the llvm-dev mailing list