Hi LLVM folks,<br><br>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.<br><br>Basically :<br>
- MCJIT : <br>  - Main class implementing ExecutionEngine interface<br>  - owns and creates :<br>    - a MemoryManager (will be a reuse of the JITMemoryManager mechanism)<br>    - a MCJITStreamer<br>    - a PassManager for scheduling of an AsmPrinter (MCLowering) using the streamer<br>
<br>- MCJITStreamer<br>  - owns and creates :<br>    - a MCAssember<br>    - a MCJITObjectWriter<br>    - a mem_raw_ostream<br>  - knows :<br>    - the MCJIT : to give it to the object writer (for mapping)<br>    - the MemoryManager : to give it to the object writer (for memory claiming)<br>
<br>- MCJITObjectWriter<br>  - knows :<br>
    - the MCJIT : for mapping GlobalVariable <-> native address<br>
    - the MemoryManager : for claiming memory<br><br>- mem_raw_ostream<br>  - The ostream interface to write data in memory<br>  - Currently using a MemoryBlock but will probably be changed for matching JITMemoryManager structure<br>
<br><br>Another point of interest is how the current mappings are implemented in the ExecutionEngine.<br><br>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.<br>
<br>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. <br>
<br>What do you think ?<br><br>Olivier.<br><br>