Implementation of orc2 based jit engine. #477
Conversation
|
alright I feel I have commented everything. Feel free to let me know anything i missed. |
|
hmmm sees i need to find out what llvm version LLJIT was added. And then rebase to master. I'll get right on that! |
| /// execution engine it came from, but adding functions after calling this | ||
| /// method *may* invalidate the function pointer. |
There was a problem hiding this comment.
There is probably a cool hack to avoid this: accept &mut self in add_* methods and store &self in LLJITFunction. In theory, this should prevent from calling mutable methods, while there is an immutable reference
There was a problem hiding this comment.
Just like you can't store references to Vec elements and push into it
| Module { | ||
| module: Cell::new(module), | ||
| owned_by_ee: RefCell::new(None), | ||
| owned_by_lljit : RefCell::new(None), |
There was a problem hiding this comment.
I wonder if we should just have one owned by field with an enum in the option?
| self.add_global_mappings_impl(mappings.iter().map(|(name,addr)| (to_c_str(name),*addr))) | ||
| } | ||
|
|
||
| fn add_global_mapping_impl(&self,name:Cow<'_,CStr>, addr:usize) -> Result<(),LLVMString> { |
TheDan64
force-pushed
the
master
branch
3 times, most recently
from
b7ef5f6 to
7684346
Compare
|
It seems that JCBurnside may have abandoned this pull request. Would it be alright if I try to implement the Orc/Orc2 JIT engine? |
| #[allow(non_snake_case)] | ||
| #[inline(always)] | ||
| pub unsafe fn call(&self, $( $param: $param ),*) -> Output { | ||
| let addr = ::std::mem::transmute::<u64,unsafe extern "C" fn($( $param ),*) -> Output>(self.addr); |
There was a problem hiding this comment.
This is undefined behavior on a 32-bit system.
|
@ErisianArchitect yes that would be fine |
|
@TheDan64 I'm currently working on support for Orc (not yet Orc2) for LLVM 8 through 11. I had a few things I wanted to discuss. 1.) When you add a module with AddCompiledIR functions, it accepts a symbol resolver function and a pointer to a context that is passed to that symbol resolver context. I was thinking that I could create a local symbol resolver the resolves symbols per-module, and a global symbol resolver that resolves symbols per-engine, and the local resolver could fallback to the global resolver if the symbol is not found in the local resolver. 2.) The Orc JIT engine symbol resolver for the AddCompiledIR functions uses mangled symbols for function names. These mangled symbols are derived from the JIT Stack. I was thinking that the local/global symbol resolvers could internally store a HashMap where the mangled symbol is the key and the value is the function pointer. 3.) It would be nice for the OrcEngine to do some cleanup when dropped, so I was thinking it would be a good idea to add the scopeguard dependency for the on Drop mechanism. It would be easier than programming it manually. I probably have some other thoughts, but that's all I've come up with so far. I'm still designing the API. |
|
The Orc V1 API is nearing completion (I didn't end up needing scopeguard after all). But there's still a major issue. When you add a module to the Orc JIT stack with eager compilation (LLVM v11) using I even tried emitting the code to an object memory buffer and then adding it to the jit stack as an object file, but the symbols still weren't resolvable. I'm not sure whether to leave that part of the API in, or if I should exclude it. Either way, the issues should be resolved in Orc V2, which I plan on starting work on either today or tomorrow. Update: I did some more digging, and it seems that this is a known limitation on Windows: https://stackoverflow.com/questions/49866755/rust-llvm-orc-jit-cannot-find-symbol-address |
4 participants
Description
It supports creating the LLJIT engine off a module (consuming said module), adding global mappings off name and global values.
Documentation needs a bit of work (thus starting this as a draft pr) but rather simple implementation and tried to mirror
JITExecutionEnginethough it is constructed differently.Related Issue
#476
How This Has Been Tested
I have tested with a local project referencing the local fork and the samples attached to
LLJITExecutionEngine::get_functionandLLJITExecutionEngine::add_global_mappingChecklist