<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - ORC addModuleSet / addModule API cleanup"
href="https://llvm.org/bugs/show_bug.cgi?id=30896">30896</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>ORC addModuleSet / addModule API cleanup
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>OrcJIT
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>lhames@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>