Questions about moving from MCJIT to Orc JIT

Hello LLVM-Mailing list,

in the past I was using the MCJIT (if I understand it correctly) to load IR modules, compile them and execute them. The speciality of this JIT was, that it was writing the compiled code into a shared memory - for a different process to execute them. For that task the JIT used a ‘custom’ memory manager, memory mapping and also resolved undefined references itself.

I was told some month ago, that MCJIT is heavily outdated and that I should move on to Orc JIT. So I did this today by reading the first Kaleidoscope Tutorial. Of course, I’m far away from having an understanding about the Orc JIT but I already miss all of the features I need to port my old JIT to the Orc JIT.

So I did some research and have some questions now:

1.) Memory Manager

I saw that I can actually replace the Memory Manager via the constructor of the “RTDyldObjectLinkingLayer” - is that correct?

2.) JITDyLib

I think, but I’m not sure, that I can use a JITDyLib to inject my own addresses for different functions, but I’m not sure how to do that - or if I’m correct with it.

3.) Legacy Layer

I later looked into the third Kaleidoscope Tutorial, seeing the “LegacyRTDyldObjectLinkingLayer” and “LegacyIRCompileLayer” - that looked promising!

But sadly the tutorial state that it was not updated yet to the new OrcJIT API - so… I have difficulties ‘trusting’ that tutorial. Does it mean, that those Legacy Layer will be removed soon? Or that you should not use them? The term legacy worries me actually.

4.) Reusing the JIT

With the MCJIT I noticed that you can not simply ‘reset’ the JIT and re-run it for a new compilation. What I mean with that is, I wanted to compile a IR module and then reset the MCJIT like it never compiled anything, so that I can set it up again, while not having to free the memory I already allocated.

Is something possible with the Orc JIT?

Thank you for your help in advance!

Kind greetings

Björn

I apologize for the “push” on this subject – but can nobody say something to this?

Hi Bjoern,
CC’ing Lang hames

For questions,

  1. In short yes, you can replace the memory manager, default one provided is section memory manager.

  2. If you mean by " address of already compiled code", yes you can do that.

Like this

JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol to the provided the Address.

  1. Yes, all the class/function with legacy prefix will be removed in subsequent releases.

  2. Could please provide some more context on this? Like it’s usage model, what goal you are aiming for?

Hey Praveen,

Thanks for your help! I still have questions and try providing some context.

For questions:

2.) I exactly mean that! Sadly I was not able to understand how to use the ‘define’ function, I tried that:

I had no idea how to deal with that >o<

2.1.) With MCJIT I was actually used to getting the name of a function and then ‘answering’ with an address. Is that behavior not possible with OrcJIT anymore? I actually tried looking into the ‘setGenerator’ function of the JITDylib. As a test I came up with this:

image002.png

This was pretty cool, because I actually saw the missing function ‘puts’ but I have no idea how to reply with an address for ‘puts’. Returning ‘Names’ actually makes the application pause and not go on.

4.) I used the code of Kaleidoscope JIT for my little experiments. If I understood it correctly, the JIT process is completed after I used the lookup function to find a symbol in the code. Now I would like to reset the instance of the Kaleidoscope JIT I had, to jit new modules, which are not related to the previous modules I jitted.

Kind greetings

Björn

Nice!
Let me try to answer some questions,

Before that I have to mention this is ORC version 2 APIs and this is where the project is moving forward.

JITDylib is the symbol table, basically for a JIT Symbol it have an associated materializers, (you can think of it like an entity that generate the address for that symbol),

Example: compiler are materializers.
So to add symbols to your own JIT you can define them in JITDylib.

For example, Suppose you want to add “your host process (on which JIT runs) symbols to the JIT”.

You can do

JD.setGenerator(DynamicLibrarySearchGenerator::GetForCurrentProcess(DL.getGlobalPrefix()))

Under hood, ORC normally search for your host symbols in the defGenerator if it can’t find symbols anywhere else.

You can look at core.cpp at line 1163 to see how it works!

I highly recommended you to watch “Updating ORC for Concurrency” dev meeting talks, it is explained in detail,
For question 4, I don’t know maybe If I know after sometime I will write here :slight_smile:

Thanks

image002.png

Thanks for the input! I was able to write my own Generator function for the JITDylib!
Thank you a lot x3

image002.png

Awesome!

image002.png