<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 --- - Design an ORC C-API / ExecutionEngine replacement"
href="https://llvm.org/bugs/show_bug.cgi?id=31103">31103</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Design an ORC C-API / ExecutionEngine replacement
</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>Along with <a href="http://llvm.org/PR31101">http://llvm.org/PR31101</a> (unifying the existing in-tree ORC stacks)
we should design a new C API for ORC. It may make sense to design a replacement
for the C++ ExecutionEngine API alongside this.
I expect the default JIT implementation for any new interface would be provided
by the unified stack developed for <a href="http://llvm.org/PR31101">http://llvm.org/PR31101</a>, and it may be worth
designing the new stack with the interface in mind.
There is an existing ORC C-API (see
<a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/OrcBindings.h">http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/OrcBindings.h</a>)
that may serve as a starting point, but it's missing some key features
(especially support for remote JITing).
A few of important questions off the top of my head:
(1) How should resource ownership (Modules, object files, etc) be modeled in
the C-API?
<a href="http://llvm.org/PR30896">http://llvm.org/PR30896</a> will significantly influence this by locking ORC to a
shared ownership model.
(2) How should remote JITing be handled?
(3) How should this interface interact with the LLVM IR interpreter (if at
all?)
Thoughts from existing clients would be most welcome.</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>