[llvm-bugs] [Bug 30896] New: ORC addModuleSet / addModule API cleanup

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=30896

            Bug ID: 30896
           Summary: ORC addModuleSet / addModule API cleanup
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: OrcJIT
          Assignee: unassignedbugs at nondot.org
          Reporter: lhames at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

There are a number of changes that could be made to addModuleSet to simplify
it, and the ORC layer classes in general.

Background:

addModuleSet is the ORC layer concept's method for adding IR to the JIT. It
takes a collection of IR Modules (using a template type for the collection), a
memory manager (a template type that must support dereference) and a symbol
resolver (also a template type that supports dereference).

The choice to have addModuleSet add a set of modules, rather than a single
module, was so that those modules could be co-located in memory. This would
enable short jumps and references between these modules. In practice, any code
wanting to achieve this effect is likely to be better off doing one of two
things:

(1) If all modules to be co-located are IR modules they are likely to be better
off being pre-linked into a single module (this enables better IR
optimization), or

(2) If the modules to be added are a mix of objects and IR modules (in which
case they can't be added in a single addModuleSet call), they can be added
using multiple calls using the same memory manager. As long as no symbol
resolution calls are made by the client between the addModuleSet calls, none of
the generated objects will be finalized, so the code can be co-located by the
memory manager during finalization.

Proposed changes:

(1) Move from addModuleSet to addModule (singular).

(2) Use shared_ptr<Module> as the module type, rather than a template argument
-- once the collection type is not a template argument, it makes sense to pin
the memory ownership model to shared in order to remove this template argument
entirely.

A lot of ORC layer code is playing type-erasure games to be able to hold the
module pointer types, so fixing this to shared_ptr<Module> would simply not
just addModuleSet but the surrounding layer code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161103/557f64e6/attachment.html>