[Mlir-commits] [mlir] [MLIR] Add support for calling conventions to LLVM::CallOp and LLVM::InvokeOp (PR #71319)

Markus Böck llvmlistbot at llvm.org
Sun Nov 5 08:15:27 PST 2023


================
@@ -1161,6 +1212,13 @@ LogicalResult CallOp::verifySymbolUses(SymbolTableCollection &symbolTable) {
       return emitOpError() << "'" << calleeName.getValue()
                            << "' does not reference a valid LLVM function";
 
+    if (fn.getCConv() != getCConv()) {
+      auto fnCConv = stringifyCConv(fn.getCConv());
+      auto callCConv = stringifyCConv(getCConv());
+      return emitOpError() << "calling convention mismatch: " << callCConv
+                           << " != " << fnCConv;
+    }
----------------
zero9178 wrote:

I don't think we should be verifying this property. The LLVM documentation only marks this as being "Undefined Behaviour" but not as an ill-formed structure. Turning undefined behaviour into a verification error is problematic as actual undefined behaviour only occurs once that instruction were to be executed. Furthermore, there could be perfectly valid code that would cause verification failure due to the above:
```mlir
%0 = isFastCC()
%1 = getCallee()
if %0 {
  call fastcc void %1()
} else {
  call void %1()
}
```
If optimizations managed to turn `getCallee` into a `SymbolRefAttr` the above program would suddenly cause verification failure despite never actually doing anything undefined.

Note that LLVM does not verify this property either: https://godbolt.org/z/W9Y4x9ezn
See also: https://mlir.llvm.org/getting_started/DeveloperGuide/#ir-verifier

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


More information about the Mlir-commits mailing list