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.