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: unassignedb...@nondot.org
Reporter: lha...@gmail.com
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
