[LLVMdev] Multiple module support in MCJIT

Eli Bendersky eliben at google.com
Wed Sep 18 08:40:10 PDT 2013


Hi Andy,

Sounds good in general. One question below:


On Tue, Sep 17, 2013 at 4:01 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:

> I'm about to start working on multiple module support in MCJIT.  I know a
> lot of people are interested in this so it seemed like a good idea to begin
> by soliciting input.
>
> My immediate plan involves the following:
>
> - Add something to the MCJIT interface to explicitly request module
> compilation
> - Isolate module-specific state variables into a structure so that the
> state of each module can be tracked independently
> - Identify intermediate objects (such as Target Machine) which have
> module-specific states and duplicate them as necessary
> - Implement a mechanism to automatically attempt to resolve external
> symbols from a module being loaded against any modules that are associated
> with the same instance of MCJIT.
>
> I do not intend (at this time) to address the case where modules have
> mutual dependencies on one another, though I imagine that will be a case
> that we'll want to handle in the future.
>

Would it be difficult to support it from the start?



> There's a bit of ugliness that has crept in where RuntimeDyld maintains a
> module-related state.  That wasn't supposed to happen and now that it has
> I'll have to do something about it.  I'll need to do a bit of experimenting
> to determine the best/easiest approach to take at this time.
>
> I expect that what I'm going to do will more or less follow the shape of
> what I wrote about in the MCJIT/Kaleidoscope blog posts a couple of months
> ago, moving whatever I can inside MCJIT.
>
> If anyone has any work in progress in this area or requirements that you
> want to make sure get addressed, please let me know very soon.
>

 Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130918/b607c86b/attachment.html>


More information about the llvm-dev mailing list