[MLIR][ExecutionEngine] Restore internal _mlir_{*} builtins

[cbalint13]

During clang-tidy fixes, _mlir_{alloc,aligned_alloc,free,aligned_free} were lost, see the commit: c599650

• Current mlir{Alloc,AlignedAlloc,Free,AlignedFree} are dangling declarations.
• This PR restores the previous behaviour and utility but also keep clang-tidy happy.

---

Issue details

• Prior to this, using mlir-runner-testcase.py.gz reveals the following missing symbols:

-> pm.add("finalize-memref-to-llvm{use-generic-functions=false}") $ ./mlir-runner-testcase.py Could not compile malloc: Symbols not found: [ _mlir_malloc ] Generated object file 'obj.o' for inspection. 

-> pm.add("finalize-memref-to-llvm{use-generic-functions=false use-aligned-alloc=1}") $ ./mlir-runner-testcase.py Could not compile aligned_alloc: Symbols not found: [ _mlir_aligned_alloc ] Generated object file 'obj.o' for inspection. 

• Using this PR, symbols resolves and are picked up properly:

$ ./mlir-runner-testcase.py Generated object file 'obj.o' for inspection. $ readelf -Ws obj.o Symbol table '.symtab' contains 7 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS LLVMDialectModule 2: 0000000000000000 98 FUNC GLOBAL DEFAULT 3 main 3: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND aligned_alloc 4: 0000000000000070 101 FUNC GLOBAL DEFAULT 3 _mlir_ciface_main 5: 00000000000000e0 108 FUNC GLOBAL DEFAULT 3 _mlir_main 6: 0000000000000150 111 FUNC GLOBAL DEFAULT 3 _mlir__mlir_ciface_main 

Note: Of course one can still use use-generic-functions=true with his own custom shared library, but the scope of this PR is to restore the functionality back to simply what libmlir_c_runner_utils.so already ships as builtins.

[llvmbot]

@llvm/pr-subscribers-mlir

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

Author: Balint Cristian (cbalint13)

Changes

During clang-tidy fixes, _mlir_{alloc,aligned_alloc,free,aligned_free} were lost, see the commit: c599650

• Current mlir{Alloc,AlignedAlloc,Free,AlignedFree} are dangling declarations.
• This PR restores the previous behaviour and utility but also keep clang-tidy happy.

---

Issue details

• Prior to this, using mlir-runner-testcase.py.gz reveals the following missing symbols:

-&gt; pm.add("finalize-memref-to-llvm{use-generic-functions=false}") $ mlir-runner-testcase.py Could not compile malloc: Symbols not found: [ _mlir_malloc ] Generated object file 'obj.o' for inspection. [cbalint@<!-- -->yoda work]$ mcedit mlir-runner-testcase.py 

-> pm.add("finalize-memref-to-llvm{use-generic-functions=false use-aligned-alloc=1}") $ mlir-runner-testcase.py Could not compile aligned_alloc: Symbols not found: [ _mlir_aligned_alloc ] Generated object file 'obj.o' for inspection. 

• Using this PR, symbols resolves and are picked up properly:

$ ./mlir-runner-testcase.py Generated object file 'obj.o' for inspection. $ readelf -Ws obj.o Symbol table '.symtab' contains 7 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS LLVMDialectModule 2: 0000000000000000 98 FUNC GLOBAL DEFAULT 3 main 3: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND aligned_alloc 4: 0000000000000070 101 FUNC GLOBAL DEFAULT 3 _mlir_ciface_main 5: 00000000000000e0 108 FUNC GLOBAL DEFAULT 3 _mlir_main 6: 0000000000000150 111 FUNC GLOBAL DEFAULT 3 _mlir__mlir_ciface_main 

Note: Of course one can still use use-generic-functions=true with his own custom shared library, but the scope of this PR is to restore a the functionality back to simply what libmlir_c_runner_utils.so already ships as builtins.

---

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

1 Files Affected:

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

diff --git a/mlir/lib/ExecutionEngine/ExecutionEngine.cpp b/mlir/lib/ExecutionEngine/ExecutionEngine.cpp index 52162a43aeae3..85775aefd1a02 100644 --- a/mlir/lib/ExecutionEngine/ExecutionEngine.cpp +++ b/mlir/lib/ExecutionEngine/ExecutionEngine.cpp @@ -134,7 +134,27 @@ void ExecutionEngine::setupTargetTripleAndDataLayout(Module *llvmModule, llvmModule->setTargetTriple(tm->getTargetTriple()); } +static StringRef lookupBuiltinCRunnerNames(StringRef name) { + static const llvm::StringMap<StringRef> nameMap = { + {"alloc", "mlirAlloc"}, + {"aligned_alloc", "mlirAlignedAlloc"}, + {"malloc", "mlirAlloc"}, + {"free", "mlirFree"}, + {"aligned_free", "mlirAlignedFree"}}; + + auto it = nameMap.find(name); + if (it != nameMap.end()) { + return it->second; + } + + return {}; +} + static std::string makePackedFunctionName(StringRef name) { + auto cfuncName = lookupBuiltinCRunnerNames(name); + if (!cfuncName.empty()) + return cfuncName.str(); + return "_mlir_" + name.str(); } 

[cbalint13]

Cc @joker-eph , @ftynse (authors / code blame list)

[ftynse]

Hmm, this sort of dynamic renaming makes the overall behavior of a system harder to follow, all just to keep the linter happy... Can we rather revert the offending commit + add configuration that prevents it from complaining about these names?

[joker-eph]

+1 to revert + a test using the symbols otherwise this is dead.

[cbalint13]

@ftynse , @joker-eph

As per review requests:

• Reverted c599650
• Protected relevant section against clang-tidy
• Extended actual testDumpToObjectFile, so it would catch failures like:

   TEST: testDumpToObjectFile {..} Could not compile malloc: Symbols not found: [ _mlir_malloc ] {..} 

[cbalint13]

Not sure it is worth, the issue would persist across (too) many older versions.
This works fine with custom libraries.