This adds minimalistic bindings for the execution engine, allowing to
invoke the JIT from the C API. This is still quite early and
experimental and shouldn't be considered stable in any way.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
1,010 ms | x64 windows > MLIR.CAPI::execution_engine.c |
Event Timeline
mlir/lib/CAPI/ExecutionEngine/ExecutionEngine.cpp | ||
---|---|---|
21 | I feel like you are going to run into trouble eventually by making the LLVM initialization implicit (as soon as being used in a context that also initializes LLVM differently). In things I've written, I've eventually had to lift all such default initialization sequences to custom functions that the top level can choose to use or not. |
mlir/lib/CAPI/ExecutionEngine/ExecutionEngine.cpp | ||
---|---|---|
21 | Yeah this is tricky and I'm not fond of these init in general... In this case is there an issue to initializing the native target? I expect that you can call multiple times the initialization and LLVM will just ignore future calls. But I may miss some adversary effect that you have in mind with a client that would "initializes LLVM differently"? |
mlir/lib/CAPI/ExecutionEngine/ExecutionEngine.cpp | ||
---|---|---|
21 | Honestly, I can't remember in this case - just memories of issues. Let's just stick with this for the moment to get started? |
clang-tidy: warning: header guard does not follow preferred style [llvm-header-guard]
not useful