llvm ir中invoke与call均为终端指令，区别仅在控制流语义：invoke用于异常处理，需配对landingpad和unwind块，支持正常返回与异常跳转两条路径；call仅单路径返回，无异常处理约束，不参与栈展开。
LLVM IR里invoke和call不是汇编里的INVOKE伪指令
很多人看到invoke就联想到MASM里的INVOKE，以为它带参数检查或更“安全”——这是常见误解。LLVM IR的invoke和call都是真实存在的终端指令（Terminator Instruction），编译器不会替你校验参数类型或个数，也不会在编译时报“少传了一个i32”。它们的区别完全在控制流语义上，和类型检查无关。
invoke必须配对landingpad，call不用
invoke是为异常处理（exception handling）设计的：它把函数调用拆成两条可能路径——正常返回走normal块，抛出异常则跳转到unwind块。这意味着：
-
invoke指令后必须紧跟两个基本块标签：to label %normal unwind label %cleanup - 对应的
%cleanup块里必须有landingpad指令来声明如何捕获异常（比如%lp = landingpad { i8*, i32 } catch i8* null） - 如果没写
landingpad或unwind目标不可达，llc或opt会报错：invalid invoke: no landingpad in unwind destination -
call没有这些约束，它只有一条返回路径，也不参与C++/Rust的栈展开流程
生成代码时，invoke不一定比call慢，但会影响优化
现代LLVM对invoke做了不少优化，比如当它能证明目标函数永不抛异常（通过nounwind属性或IPA分析），就会自动降级为call。但要注意：
- 只要存在
invoke，LLVM就必须保留栈帧信息、禁用某些尾调用优化（如tail call不能用于invoke） - 函数声明带
nounwind（如declare i32 @puts(i8*) nounwind）时，用call更自然；若硬写invoke，虽不报错，但多余 - 跨语言互操作时（比如C调用Rust函数），Rust ABI要求关键边界用
invoke，否则panic时无法正确回溯
什么时候该选invoke而不是call
判断依据只有一个：你是否需要响应被调函数抛出的异常。不是“想更规范”，也不是“听说它更安全”。
- 写纯C代码且不链接C++运行时？几乎总用
call - 函数签名明确标了
nounwind或noexcept？用call，invoke是冗余的 - 调用的是
std::vector::at()这类可能throw的C++函数，且你写了catch逻辑？必须用invoke+landingpad - 手写IR做模糊测试或插桩？
invoke能帮你精确控制异常入口点，但得自己维护unwind链
最容易被忽略的一点：LLVM IR本身不实现异常处理，它只提供骨架。invoke是否真能捕获异常，取决于你链接的运行时（libunwind、libc++abi）和后端生成的EH table是否匹配。光写对IR，不配好链接选项，unwind块永远执行不到。
