JIT with MC - structure

Project Infrastructure LLVM Dev List Archives
1

Hi LLVM folks,

Attached with this email, you will find a patch not directly applicable (it doesn’t compile like this) which (try to) enhance the structure of a possible JIT with the MC framework.

Basically :

  • MCJIT :

  • Main class implementing ExecutionEngine interface

  • owns and creates :

  • a MemoryManager (will be a reuse of the JITMemoryManager mechanism)

  • a MCJITStreamer

  • a PassManager for scheduling of an AsmPrinter (MCLowering) using the streamer

  • MCJITStreamer

  • owns and creates :

  • a MCAssember

  • a MCJITObjectWriter

  • a mem_raw_ostream

  • knows :

  • the MCJIT : to give it to the object writer (for mapping)

  • the MemoryManager : to give it to the object writer (for memory claiming)

  • MCJITObjectWriter

  • knows :

  • the MCJIT : for mapping GlobalVariable <-> native address

  • the MemoryManager : for claiming memory

  • mem_raw_ostream

  • The ostream interface to write data in memory

  • Currently using a MemoryBlock but will probably be changed for matching JITMemoryManager structure

Another point of interest is how the current mappings are implemented in the ExecutionEngine.

When applying fixups in the ObjectWriter, we get a symbol name from a MCSymbol. With the current mappings the Writer is forced to know the Module, to search for Global named like the MCSymbol. This global is then used to retrieve a native address.

It will be probably more efficient to use a direct mapping StringRef <-> native address. We can keep an overloaded method for GlobalVariable <-> native address, if this is necessary for compatibility or easiness of use.

What do you think ?

Olivier.

mc_jit_structure.diff (21.3 KB)

2

I've only glanced at it, but it seems like a reasonable start. Hopefully I'll get a bit more time in the next week or so to give a more thorough going-over.

-eric

3

Thanks for the feedback !

Any thoughts about global mapping based on (global variable <-> native address) vs (name <-> native address) ?

Olivier.

4

Hi all!

I finally got a chance to review this work over the weekend. Once
again, sincere apologies for the delay.

I have a few concerns with the approach this patch is taking.
Ultimately, I came to the opinion that I would rather not proceed down
this particular path, because I think it will take us in (slightly)
the wrong direction, and it will be hard to refactor towards what I
consider a more "ideal" solution.

I am about to send out another email describing more about the
direction I would like to take. I'm hoping I can get you guys on board
with that approach, and then we can chart a path forward.

- Daniel