ptrtoint和inttoptr是llvm ir中唯一合法的指针与整数双向转换指令对，要求整数位宽足以容纳指针（如x86_64上必须用i64），且必须成对使用；bitcast严禁用于指针-整数转换，addrspacecast仅用于地址空间切换。
ptrtoint 和 inttoptr 指令必须成对使用
LLVM IR 中整数与指针互转不是自由转换，ptrtoint 和 inttoptr 是唯一合法的双向指令对。它们不改变位模式，只做类型重解释——这要求目标整数类型宽度必须足以容纳指针值（通常为 i64 在 x86_64 上），否则行为未定义。
常见错误现象：
-
ptrtoint i32* %p to i32在 64 位平台触发llc报错：invalid cast: ptrtoint with mismatched sizes - 单独用
ptrtoint得到整数后没用inttoptr回转，而是直接参与算术运算（如加偏移），再强制 reinterpret_cast —— 这在 IR 层属于类型违规，优化器可能误删或重排
实操建议：
- 始终用
ptrtoint i8*转成足够宽的整数，例如ptrtoint i8* %p to i64 - 若需计算地址偏移，先转整数、加减、再用
inttoptr回转：%addr = inttoptr i64 %off to i32* - 避免跨函数边界传递中间整数值：函数参数/返回值应保持指针类型，除非你明确在写底层运行时（如 GC 扫描逻辑）
bitcast 不能替代 ptrtoint/inttoptr
bitcast 只能在“位宽相同且都是一等类型”的前提下做零成本重解释，比如 i32 ↔ float，或 i8* ↔ i32*。但它**不允许**在指针和整数之间转换——LLVM 类型系统严格禁止。
典型错误：
-
bitcast i32* %p to i64→ 编译时报错：invalid bitcast - 试图用
bitcast绕过ptrtoint的类型检查，结果在opt或llc阶段被拦截
为什么这样设计？因为 bitcast 假设两端语义等价，而指针和整数在内存模型、别名分析、优化规则上完全不同。让编译器知道“这里发生了地址到整数的语义跃迁”，是后续正确优化（如 alias analysis、GVN）的前提。
AddrSpaceCast 用于地址空间切换，不是类型转换
如果你在 GPU 或嵌入式环境工作，可能遇到不同地址空间的指针（如 addrspace(1) global vs addrspace(0) generic）。这时要用 addrspacecast，而不是 ptrtoint。
关键区别：
-
addrspacecast i32 addrspace(1)* %p to i32 addrspace(0)*：合法，仅改地址空间标识 -
ptrtoint i32 addrspace(1)* %p to i64：也合法，但语义是“把该地址空间里的指针值当纯数字取出来” - 二者不可混用；
addrspacecast不涉及整数，也不改变位宽
容易踩的坑：在 OpenCL 或 CUDA 后端中，误用 ptrtoint 处理跨地址空间指针，导致生成非法汇编或运行时访问违例。
实际调试时怎么看转换是否生效
生成 IR 后，用 llvm-dis 反解 bitcode，然后 grep 关键字：
-
grep -n "ptrtoint\|inttoptr" file.ll确认指令存在且配对 - 检查整数类型宽度是否匹配目标平台指针大小（
target triple决定，如x86_64-pc-linux-gnu→ 用i64） - 运行
opt -mem2reg -instcombine file.ll -o opt.ll后再检查——某些冗余转换会被优化掉，但合法的ptrtoint/inttoptr对通常保留
最易忽略的一点：LLVM 不验证 inttoptr 的整数值是否指向合法内存。它只保证指令本身可生成，运行时崩溃得靠你自己的地址合法性检查。
