This patch exports the symbolds of the mlir_async_runtime library as
visible symbols (i.e., nm shows them as T instead of t). This is
necessary to be able to use load the library into the (Python binding
of) the execution engine, which, otherwise, can't see those symbols. The
symbols are made visible with the same mechanism as this is done in the
mlir_runner_utils and mlir_c_runner_utils (the main macro is copied from
there), which export the symbols for the same reason.
Details
- Reviewers
ezhulenev mehdi_amini
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It shouldn't be needed, we expose a __mlir_runner_init symbol that register these functions explicitly with the JIT ExecutionEngine in JitRunner.cpp.
Instead of relying on symbol visibility, can we look into generalizing this kind of runtime library initialization?
To make sure I understand you and the current mechanisms correctly: the mechanism with __mlir_runner_init is currently used by mlir-cpu-runner for finding the exported symbols from the async runtime. This works even though the symbols in that library do not have public visibility. What you are proposing is (1) to have the execution engine load symbols through the same mechanism and potentially (2) to have other libraries (like the runner utils and the C runner utils) use the same mechanism (and revert their symbols back to private visibility (t)). Is that correct?
Yes: that seems more robust that relying on "polluting" the global namespace of the running binary with implicitly loading "all symbols from this shared library".
The JIT engine could just always look for a "magic" symbol to initialize a shared library on loading.
https://reviews.llvm.org/D153029 now contains a first stab at what I think you meant.