llvm ir禁止隐式类型转换，因其是强类型ssa形式，要求指令输入/输出类型精确匹配，以支撑跨阶段优化与后端确定性代码生成；所有类型变更必须显式使用bitcast、zext、sext等指令。
LLVM IR 不支持隐式类型转换，所有类型变更必须显式插入 bitcast、zext、sext、trunc 或 fpext/fptrunc 等转换指令。试图直接把 i32 当作 i64 用，或把 float 直接传给要求 double 的函数，会触发 verifier 错误并中止生成。
为什么 LLVM IR 禁止隐式转换
LLVM 是强类型 SSA 形式，每条指令的输入/输出类型都必须精确匹配。这不是设计疏漏，而是为了支撑跨阶段优化（如常量传播、死代码消除）和后端代码生成的确定性。C 语言里 int + long 自动提升为 long 这类语义，在 IR 层面已由前端（如 Clang）在 lowering 阶段展开为显式转换 + 运算指令组合。
- IR verifier 会在
llvm::verifyModule()或llc编译时立即报错，典型错误如：Instruction does not dominate all uses!（类型不匹配导致 PHI 节点类型冲突）或Invalid cast opcode for cast from 'i32' to 'i64' - Clang 生成的 IR 中常见模式是：先
sext i32 %0 to i64，再用add i64；而不是让add自己“猜”怎么处理混合宽度操作数 - TableGen 描述的指令选择规则也依赖精确类型——
ADDrr和ADD64rr是两条不同 pattern，不能靠隐式升宽自动 fallback
常见类型转换场景与对应指令选择
选错转换指令会导致静默语义错误（如符号位丢失）或 verifier 拒绝。关键看源/目标类型是否同宽、是否有符号性差异、是否浮点/整数互转：
-
i8 → i32（零扩展）：用zext i8 %0 to i32；若原值是无符号小整数（如字节），这是正确做法 -
i8 → i32（符号扩展）：用sext i8 %0 to i32；用于有符号 char 或 int8_t 场景，保留最高位作为符号位 -
i32 → i8：必须trunc i32 %0 to i8；不能省略，否则 verifier 报Cannot bitcast between types of different sizes -
float → double：用fpext float %0 to double；bitcast在这里非法，因为 IEEE754 二进制表示不同 -
ptr → i64（地址转整数）：必须ptrtoint ptr %0 to i64；反过来用inttoptr i64 %0 to ptr；bitcast仅适用于位宽相同且内存布局兼容的类型（如float↔i32）
自定义 Pass 中容易踩的坑
在写 LLVM Pass 修改 IR 时，类型转换常被忽略或硬编码，导致跨平台失败（如 x86_64 vs AArch64 指针宽度不同）：
- 别写死
i64：指针相关计算应使用getIntPtrType(module->getDataLayout())获取当前 target 的指针整数类型 - 避免
bitcast替代语义转换：例如把float*bitcast成i32*再load，虽能过 verifier，但违反 strict aliasing，后端可能生成错误代码 - 调用外部函数前务必检查签名：用
function->getFunctionType()->getParamType(i)对比实际参数类型，不匹配就插转换；Clang 生成的@printf声明要求i32，传i64必须先trunc - 递归类型处理（如 struct 成员）：若 struct 含
i16字段，而目标 ABI 要求 4 字节对齐，不能只改字段类型，得同步调整getelementptr索引和 padding —— 这由DataLayout控制，不是靠手动zext能解决的
最常被忽略的一点：类型转换指令本身也有类型约束。zext 只接受整数到更宽整数，fpext 只接受浮点到更宽浮点；拿 double 用 zext 会直接 crash，而不是报错提示。写 Pass 时务必用 CastInst::isCastable 预检，而不是靠 try/catch。
