[llvm-bugs] [Bug 31103] New: Design an ORC C-API / ExecutionEngine replacement

[via llvm-bugs]

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

            Bug ID: 31103
           Summary: Design an ORC C-API / ExecutionEngine replacement
           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

Along with http://llvm.org/PR31101 (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 http://llvm.org/PR31101, and it may be worth
designing the new stack with the interface in mind.

There is an existing ORC C-API (see
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/OrcBindings.h)
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?
http://llvm.org/PR30896 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.

-- 
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/20161121/2562faee/attachment-0001.html>