[LLVMdev] JIT with MC - structure

[Daniel Dunbar]

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

On Thu, Sep 30, 2010 at 9:52 AM, Olivier Meurant
<meurant.olivier at gmail.com> wrote:
> 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.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>