LLVM IR中整数位宽变化必须显式使用sext（有符号扩展）或zext（无符号扩展）指令，不可用add、shl等替代；否则破坏类型安全，导致验证失败或错误代码生成。
整数扩展用 sext 和 zext，不是加法或位移
LLVM IR 中整数位宽变化必须显式使用扩展指令，不能靠 add、shl 或手动拼接实现。否则会破坏类型安全，导致验证失败（Invalid cast 错误）或后端生成错误机器码。
常见错误现象：llc 报错 Instruction does not dominate all uses 或 Invalid bitcast，往往是因为漏写 sext/zext 就直接参与运算。
-
sext：有符号扩展，高位补符号位。例如i8 -1→i32 -1（即0xFF→0xFFFFFFFF） -
zext：无符号扩展，高位补零。例如i8 255→i32 255（即0xFF→0x000000FF） - 两者都要求源类型和目标类型均为整型，且目标位宽严格大于源位宽
示例：
%a = trunc i32 1000 to i8 ; i32 → i8，先截断 %b = sext i8 %a to i32 ; i8 → i32，有符号扩展（结果为 -24） %c = zext i8 %a to i32 ; i8 → i32，无符号扩展（结果为 1000）
截断必须用 trunc，且目标位宽必须更小
trunc 是唯一合法的整数向下位宽转换方式。它不检查值是否可表示——直接丢弃高位，保留低位。这和 C 的强制转换行为一致，但 LLVM 不做隐式截断。
容易踩的坑：
- 对浮点数用
trunc：非法，会触发Verifier failure: Invalid cast - 目标类型位宽 ≥ 源类型：LLVM 验证器直接拒绝，如
trunc i8 %x to i16语法错误 - 用
bitcast替代trunc：仅当类型位宽相等时合法，i32→i8不能bitcast
典型场景：从 getelementptr 计算偏移后得到 i64，但数组索引只需 i32（在 32 位目标上）：
%idx64 = getelementptr inbounds i32, i32* %base, i64 %offset %idx32 = trunc i64 %offset to i32 ; 必须显式截断，不能省略
trunc 和 sext/zext 的组合顺序不能颠倒
扩展和截断是不可交换的操作。比如先 zext 再 trunc 不等于原值；先 trunc 再 sext 可能改变语义（符号位丢失）。
关键判断点：
- 若原始值可能为负，且你希望保持其有符号含义，应避免先
trunc后zext（会把负数转成大正数） - 若原始值确定为非负（如数组长度、计数器），
zext更安全；否则优先用sext - 在跨平台 IR 中，
i32→i64扩展推荐统一用sext，除非明确需要零扩展语义（如处理地址高位）
反例（危险）：
%x = trunc i64 0xFFFFFFFFFFFFFFFF to i32 ; 得到 0xFFFFFFFF（即 -1） %y = zext i32 %x to i64 ; 得到 0x00000000FFFFFFFF（即 4294967295），不再是原值
向量类型的 trunc/zext/sext 用法一致但需对齐
向量扩展/截断要求所有元素类型统一变化，且目标向量长度必须与源向量相同。例如 → 合法，但 → 非法。
常见错误：
- 误以为
trunc <2 x i16> <i16 1000, i16 2000> to <2 x i8>会报错——其实不会，只要每个元素可截断（1000 > 255，结果是<i8 232, i8 208>） - 对
使用trunc：类型不匹配，必须用fptrunc - 混合标量与向量操作时，忘记先用
extractelement拆出单个元素再扩展
正确示例：
%v16 = <2 x i16> <i16 257, i16 123> %v8 = trunc <2 x i16> %v16 to <2 x i8> ; 得 <i8 1, i8 123>
最易被忽略的一点：LLVM IR 验证器在 opt 或 llc 阶段才检查这些指令的合法性，而前端（如 clang）生成的 IR 通常已规避大部分问题。一旦手写 IR 或自定义 Pass 修改类型，必须确保每处位宽变化都有对应指令，且参数类型严格匹配——少一个 sext，整个模块就可能无法通过验证。
