llvm ir中调用约定通过ccn或名称（如fastcc）在define/declare返回类型前显式指定，且call指令必须严格匹配；常见值有ccc、fastcc、coldcc、cc10等，数字型须写全，不支持简写，且跨模块声明与定义、调用点必须完全一致，否则触发verifier error或abi错误。
在 define 或 declare 中直接加关键字
LLVM IR 里指定调用约定，是在函数定义或声明语句开头、返回类型前插入 cc 后接数字或名称。语法形如：define cc10 i32 @foo(i32 %x) 或 declare fastcc void @bar()。
常见可选值有：ccc（默认 C 调用）、fastcc、coldcc、cc10（GHC）、cc11（HiPE）、webkit_jscc 等。注意：数字型如 cc10 必须写全，不能简写为 10 或 ghc。
容易踩的坑：
-
cc关键字必须紧挨在返回类型之前，中间不能换行或空格错位，否则解析失败 - 同一个函数的
declare和define必须使用完全相同的调用约定，否则链接或优化时行为未定义 -
fastcc和coldcc不支持变长参数（...），若函数签名含...却用了它们，llc 会报错
call 指令里也得同步写
调用点（call）必须显式匹配被调函数的调用约定，否则 LLVM 会拒绝验证通过。例如：
define fastcc i32 @callee() { ret i32 42 }
define i32 @caller() {
%r = call fastcc i32 @callee()
ret i32 %r
}
如果把 call fastcc i32 @callee() 写成 call i32 @callee()（即省略 fastcc），即使函数定义写了 fastcc，也会触发 verifier error：Calling convention mismatch on call。
关键点：
-
call的调用约定必须和目标函数定义/声明一致，不是“可选”而是强制要求 - 对
declare的外部函数（如 libc 函数），call里不写约定，默认按ccc处理；但若你declare ccc却在call里写fastcc，同样报错 - 内联汇编（
callbr）或 patchpoint 场景下，约定更敏感，比如anyregcc只能用于llvm.experimental.patchpoint
不同调用约定对参数传递和寄存器的影响
约定不是装饰——它直接决定 ABI 行为。例如：
-
ccc：参数压栈为主，部分平台用寄存器传前几个整数，支持...，调用者清理栈 -
fastcc：尽可能全用寄存器传参（x86-64 下最多 6 个整数 + 8 个浮点），不保存 callee-saved 寄存器，尾调用不自动优化 -
coldcc：调用前保存所有 caller-saved 寄存器，适合异常处理路径等低频调用，但禁止内联 -
cc10（GHC）：X86-64 下只支持 ≤10 位整型参数和最多 6 个浮点参数，且要求调用者/被调用者都用cc10才能做尾调用优化
性能提示：盲目用 fastcc 不一定更快。如果函数体极短但调用频繁，寄存器压力可能反而升高；而 coldcc 在 hot path 上用会导致大量冗余 save/restore。
验证是否生效：看生成的汇编或用 opt -verify
最直接的办法是用 llc 输出汇编，观察参数如何传入。比如：
define fastcc i32 @f(i32 %a, i32 %b) { ret i32 %a }
在 x86-64 下，llc f.ll -o f.s 会看到 %a 在 %rdi、%b 在 %rsi —— 这就是 fastcc 的寄存器传参证据；而 ccc 版本通常从 %rdi 开始，但第 5 个参数起就进栈了。
调试建议：
- 用
opt -verify f.ll可提前捕获调用约定不匹配问题 - 用
llvm-dis反解 bitcode 后检查define行是否保留了ccN前缀（有时优化 pass 会 strip 掉非标准约定） -
cc10/cc11等非常规约定，在非 X86 目标上会被静默忽略或报错，务必确认 triple 匹配
真正麻烦的不是写错关键字，而是跨模块时一处漏写、一处多写，导致运行时栈错位或寄存器污染——这种 bug 往往不崩溃，只在特定输入下算出错值。
