[Mlir-commits] [mlir] [MLIR] Split ExecutionEngine Initialization out of ctor into an explicit method call (PR #153524)
Shenghang Tsai
llvmlistbot at llvm.org
Fri Aug 15 02:13:06 PDT 2025
================
@@ -124,6 +124,17 @@ NB_MODULE(_mlirExecutionEngine, m) {
},
nb::arg("name"), nb::arg("callback"),
"Register `callback` as the runtime symbol `name`.")
+ .def(
+ "initialize",
+ [](PyExecutionEngine &executionEngine) {
+ mlirExecutionEngineInitialize(executionEngine.get());
+ },
+ "Initialize the ExecutionEngine. Global constructors specified by "
+ "`llvm.mlir.global_ctors` will be run. One common scenario is that "
+ "kernel binary compiled from `gpu.module` gets loaded during "
+ "initialization. Make sure all symbols are resolvable before "
+ "initialization by calling `raw_register_runtime` or including "
+ "shared libraries.")
----------------
jackalcooper wrote:
> By the way: now that invoke is doing initialize() lazily, is this still useful to expose to python users?
yes it is because python API has `raw_register_runtime` which calls `mlirExecutionEngineRegisterSymbol`. As long as user of one binding can use `mlirExecutionEngineRegisterSymbol` to register symbol, the exposure would be useful. The symbol resolution would fail even the global ctors don't use the unregistered ones(also possible to fix it from this direction if ORC allows us only resolve symbols actually needed by the ctors).
https://github.com/llvm/llvm-project/pull/153524
More information about the Mlir-commits
mailing list