[Mlir-commits] [mlir] [mlir] Fix conflict of user defined reserved functions with internal prototypes (PR #123378)

Christian Ulmann llvmlistbot at llvm.org
Mon Jan 20 07:07:44 PST 2025


================
@@ -48,53 +48,74 @@ static constexpr llvm::StringRef kMemRefCopy = "memrefCopy";
 LLVM::LLVMFuncOp mlir::LLVM::lookupOrCreateFn(Operation *moduleOp,
                                               StringRef name,
                                               ArrayRef<Type> paramTypes,
-                                              Type resultType, bool isVarArg) {
+                                              Type resultType, bool isVarArg,
+                                              bool isReserved) {
   assert(moduleOp->hasTrait<OpTrait::SymbolTable>() &&
          "expected SymbolTable operation");
   auto func = llvm::dyn_cast_or_null<LLVM::LLVMFuncOp>(
       SymbolTable::lookupSymbolIn(moduleOp, name));
-  if (func)
+  auto funcT = LLVMFunctionType::get(resultType, paramTypes, isVarArg);
+  // Assert the signature of the found function is same as expected
+  if (func) {
+    if (funcT != func.getFunctionType()) {
+      if (isReserved) {
+        func.emitError("redefinition of reserved function '" + name +
+                       "' of different type ")
+            .append(func.getFunctionType())
+            .append(" is prohibited");
+        exit(0);
----------------
Dinistro wrote:

Do we consider this a user error or a programmer error? If a "user" can reach this, then this should be a proper error handling, not just an exit call. To do so, this function will have to return a `FailureOr` or some other result that can encode an error, as aborting like this in the middle is not how we deal with such kind of errors.

If this is only possible to hit by someone who implemented a pass incorrectly, an assertion would be acceptable.

https://github.com/llvm/llvm-project/pull/123378


More information about the Mlir-commits mailing list