MLIR中函数必须用func.func定义，显式声明类型、返回值并以func.return终止；调用需用func.call且参数类型严格匹配；func.return不可省略或替换，旧std方言已废弃。
func方言里怎么定义函数
MLIR 的 func 方言（现为 func dialect，旧版叫 std）是定义和组织函数的标准方式。它要求显式声明参数类型、返回类型、函数体块，并用 func.return 终止。不支持隐式返回或省略类型。
常见错误现象：写成 func @foo() { ... } 缺少类型签名 → 报错 expected function type；或漏掉 func.return → IR 验证失败，提示 block not terminated。
-
func.func是定义函数的操作名，不是关键字，必须带完整命名空间（func.func，不是func或function） - 参数和返回类型必须写在括号内，格式为
(%arg0 : i32, %arg1 : f32) -> (i32)，即使单返回也要用括号 - 函数体必须是一个
Region，里面至少有一个Block，且该Block必须以func.return或func.call等 terminator 操作结尾 - 函数名以
@开头，如@add；变量名以%开头，如%result
示例：
func.func @add(%a : i32, %b : i32) -> i32 {
%sum = arith.addi %a, %b : i32
func.return %sum : i32
}
func方言里怎么调用函数
调用必须用 func.call，不能用 call 或裸函数名。调用前需确保被调函数已在模块中定义或声明（func.func 或 func.func external），否则 mlir-opt 会报 use of undefined symbol。
容易踩的坑：传参个数/类型不匹配不报编译错误，但后续 lowering（比如到 LLVM）时会崩溃或生成非法 IR；另外，func.call 的结果必须绑定到新值名（%ret），不能丢弃。
-
func.call的第一个 operand 是符号引用（@add），不是字符串字面量，也不是"add" - 参数列表必须与目标函数签名完全一致，包括顺序、数量、类型；
i32和index不可混用 - 如果被调函数有多个返回值，
func.call返回一个元组值，需用结构化绑定或std.tuple_extract（取决于方言版本） - 跨模块调用需用
func.func external声明，且符号名必须全局唯一
示例：
func.func @main() -> i32 {
%x = arith.constant 2 : i32
%y = arith.constant 3 : i32
%z = func.call @add(%x, %y) : (i32, i32) -> i32
func.return %z : i32
}
为什么 func.return 不能省略，也不能用其他 terminator 替代
func.return 是 func 方言强制要求的 terminator，它携带返回值语义并参与类型检查。用 std.return（旧 std dialect）、cf.return 或直接 return 都会触发验证失败，因为这些操作不属于 func 方言，类型系统无法推导控制流出口与函数签名的匹配关系。
性能影响：无额外开销，func.return 在 lowering 到 LLVM 时直接映射为 ret 指令；但若误用非 func terminator，会导致 mlir-opt --convert-func-to-llvm 等 pass 跳过该函数或中途 abort。
- LLVM lowering 要求所有
func.func函数块以func.return结尾，否则转换失败并报failed to legalize operation 'func.return'类似错误 - 如果你在写自定义 Pass，访问函数返回值必须通过
func::ReturnOp，而非泛化的Operation::hasTrait<:isterminator>()</:isterminator> - 没有
void返回：即使函数不返回值，也得写-> ()并用func.return，不能省略返回部分
func方言和旧 std dialect 的兼容性陷阱
MLIR 16.0+ 已将函数相关操作全迁入 func dialect，std.func、std.return 等已废弃。但很多文档、示例甚至部分工具链（如某些 mlir-translate 版本）仍默认启用 std，导致混合使用时 silently 失败。
典型症状：func.func 定义能 parse，但 func.call 报 unknown operation 'func.call'；或 mlir-opt --convert-std-to-llvm 成功，而 --convert-func-to-llvm 报未注册 dialect。
- 确认 dialect 启用：命令行加
--load-pass-plugin=libMLIRFuncTransforms.so（若手动构建）或确保 build 时启用了MLIRFuncDialect - CMake 构建 LLVM/MLIR 时必须包含
-DLLVM_ENABLE_PROJECTS=mlir，且不能漏掉MLIRFuncDialect库（通常自动启用） - 检查 IR 是否合法：用
mlir-opt --verify-diagnostics input.mlir，它会明确指出哪个操作属于未注册 dialect - 避免混用：不要在一个 .mlir 文件里同时出现
func.func和std.func；迁移旧代码时，把所有std.前缀换成func.，并更新 terminator 和调用语法
真正容易被忽略的是：函数签名中的类型必须是 func dialect 兼容的底层类型（如 i32、f64、tensor），不能是方言专属类型（如 torch.vtensor）——除非你已注册对应 conversion pattern。否则 func.call 会因类型不可表示而卡在 lowering 第一步。
