[MLIR][ExecutionEngine] don't dump decls

[makslevental]

Currently ExecutionEngine tries to dump all functions declared in the module, even those which are "external" (i.e., linked/loaded at runtime). E.g.

func.func private @printF32(f32)
func.func @supported_arg_types(%arg0: i32, %arg1: f32) {
  call @printF32(%arg1) : (f32) -> ()
  return
}

fails with

Could not compile printF32:
  Symbols not found: [ __mlir_printF32 ]
Program aborted due to an unhandled Error:
Symbols not found: [ __mlir_printF32 ]

even though printF32 can be provided at final build time (i.e., when the object file is linked to some executable or shlib). E.g, if our own libmlir_c_runner_utils is linked.

So just skip functions which have no bodies during dump (i.e., are decls without defns).

[llvmbot]

@llvm/pr-subscribers-mlir-execution-engine

@llvm/pr-subscribers-mlir

Author: Maksim Levental (makslevental)

Changes

Currently ExecutionEngine tries to dump all functions declared in the module, even thoughs which "external" (i.e., linked at runtime). E.g.

module {
  func.func @<!-- -->supported_arg_types(%arg0: i32, %arg1: f32) {
    vector.print %arg0 : i32
    vector.print %arg1 : f32
    return
  }
}

fails with

Could not compile printF32:
  Symbols not found: [ __mlir_printF32 ]
Program aborted due to an unhandled Error:
Symbols not found: [ __mlir_printF32 ]

even though mlir_printF32 can and is provided by our own libmlir_c_runner_utils, which is usually loaded by the engine but of course can also be linked/loaded at runtime by whatever thing links the object file produced from the above.

So just skip functions which have no bodies during dump (i.e., are decls without defns).

---

Full diff: https://github.com/llvm/llvm-project/pull/164478.diff

1 Files Affected:

• (modified) mlir/lib/ExecutionEngine/ExecutionEngine.cpp (+2)

diff --git a/mlir/lib/ExecutionEngine/ExecutionEngine.cpp b/mlir/lib/ExecutionEngine/ExecutionEngine.cpp
index 52162a43aeae3..2255633c746b3 100644
--- a/mlir/lib/ExecutionEngine/ExecutionEngine.cpp
+++ b/mlir/lib/ExecutionEngine/ExecutionEngine.cpp
@@ -239,6 +239,8 @@ ExecutionEngine::create(Operation *m, const ExecutionEngineOptions &options,
   // Remember all entry-points if object dumping is enabled.
   if (options.enableObjectDump) {
     for (auto funcOp : m->getRegion(0).getOps<LLVM::LLVMFuncOp>()) {
+      if (funcOp.getBlocks().empty())
+        continue;
       StringRef funcName = funcOp.getSymName();
       engine->functionNames.push_back(funcName.str());
     }

[makslevental]

Note, I would prefer to perform this check in

llvm-project/mlir/lib/ExecutionEngine/ExecutionEngine.cpp

Line 101 in 73f651f

void ExecutionEngine::dumpToObjectFile(StringRef filename) {

but by that point the module is not accessible.

[makslevental]

looks like I (potentially) broke lots of tests in this PR #157176 because mlir/test/lit.cfg.py tries to call mlir-runner (which might not be built):

llvm-project/mlir/test/lit.cfg.py

Lines 354 to 355 in 3bca1e4

	def have_host_jit_feature_support(feature_name):
	mlir_runner_exe = lit.util.which("mlir-runner", config.mlir_tools_dir)

[makslevental]

Note, I double checked and this is the only tool that's required.