LLVM IR中没有“函数指针类型”，不能使用void ()*等C风格语法；函数地址必须通过bitcast转为i8*（或ptr）后存储或传递，并在call指令中显式声明签名，如call i32 %fp(i32 42)。
LLVM IR里函数指针是i8*还是void ()*？
都不是。LLVM IR中**没有“函数指针类型”这一独立类型**，函数地址只能通过ptrtoint或inttoptr在整数和通用指针间来回转换，最终落地为i8*（或更常见的是ptr，在新版IR中等价于i8*）。你不能直接写void ()*——这种C风格的函数指针语法在IR中非法，会报错error: expected type。
原因很简单：LLVM IR是强类型、静态单赋值的，而“指向任意函数”的抽象无法被精确类型化。所有函数都有明确签名，比如i32 (i32, i32)*，但这个类型只表示“指向符合该签名的函数”，它本身不是可存储的类型；真正能存进变量或内存的，必须是地址值，即整数或i8*。
- 正确做法：先用
bitcast把函数名转成i8*，再ptrtoint转成整数暂存，或直接store到i8*变量里 - 错误写法：
%fp = alloca void ()*→ 语法错误，IR parser直接拒绝 - 典型场景：实现函数表、回调注册、动态分发（如vtable模拟）
call指令怎么调用运行时决定的函数？
必须用call的**间接调用形式**，即不写函数名，而用一个i8*（或经bitcast转来的具体函数指针类型）作为操作数，并显式指定调用签名。格式是：call <ret_type><func_ptr_val>(<arg_types><args>)</args></arg_types></func_ptr_val></ret_type>，其中<func_ptr_val></func_ptr_val>必须是计算出来的值，不能是函数名字面量。
关键点在于：IR要求你**提前声明调用的完整类型签名**，哪怕目标函数地址是运行时才确定的。编译器不会帮你推导——它只认你写的i32 (i32)*这类类型。
- 示例：假设你有个
i8*变量%fp，想调用它指向的i32(i32)函数：%r = call i32 %fp(i32 42) - 如果签名不匹配（比如
%fp实际指向void(i32)但你写了i32 %fp(i32)），链接或运行时可能崩溃，IR验证阶段通常不报错 - 必须确保
%fp确实持有合法函数入口地址，否则call触发segfault——IR不做空指针检查
为什么bitcast @foo to i8*比ptrtoint @foo to i64更常用？
因为i8*是IR中事实上的“通用指针”载体，兼容所有内存操作（load、store、getelementptr），而整数地址必须先inttoptr才能参与指针运算。用i8*省去来回转换，减少出错机会。
但要注意：bitcast本身不改变位模式，只是重解释类型；它要求源和目标类型尺寸一致（函数名是常量地址，@foo在IR中是void ()*隐式类型，bitcast到i8*合法）。
- 安全链路：
%fp = bitcast void ()* @foo to i8*→store i8* %fp, i8** %fp_slot→%f = load i8*, i8** %fp_slot→call i32 %f(i32 1) - 危险链路：
%addr = ptrtoint void ()* @foo to i64→ 若后续忘了inttoptr就call，会触发invalid operand type错误 - 64位系统下
i64足够存地址，但32位平台要用i32，硬编码整数宽度易导致跨平台失败
间接调用绕不开noalias和nocapture这些属性吗？
不绕不开，但**可以不写**——这些是优化提示，不是语法必需。不加不影响IR合法性或功能正确性，只影响后端生成的机器码质量。
比如call i32 %fp(i32 42)本身完全合法。但加上nocapture（告诉优化器该指针参数不会被函数存起来）或noalias（返回指针不与其他指针别名），能让opt更激进地做寄存器分配或内存访问重排。
- 常见组合：
call noalias nocapture i32 %fp(i32 42) - 漏写后果：优化器保守处理，可能保留多余
load/store，性能略差，但行为不变 - 真正要小心的是
tail call和musttail——间接调用不支持尾调用优化，强行加会报错invalid tail call on indirect call
最易被忽略的一点：LLVM IR不校验函数指针的实际签名与call指令声明的是否一致。类型匹配全靠人肉保证，一旦错配，错误发生在链接后或运行时，调试成本很高。
