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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100930/6872dd26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mc_jit_structure.diff
Type: text/x-patch
Size: 21760 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100930/6872dd26/attachment.bin>
On Sep 30, 2010, at 9:52 AM, Olivier Meurant wrote:> What do you think ?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
Thanks for the feedback ! Any thoughts about global mapping based on (global variable <-> native address) vs (name <-> native address) ? Olivier. On Sat, Oct 9, 2010 at 1:48 AM, Eric Christopher <echristo at apple.com> wrote:> > On Sep 30, 2010, at 9:52 AM, Olivier Meurant wrote: > > > What do you think ? > > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101009/a38a50b8/attachment.html>
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 > >