std::bit_cast仅在源与目标类型大小严格相等且均为平凡可复制时合法，用于安全重解释位模式而不改变比特位，禁止用于指针、虚函数类、引用或大小不匹配类型。
bitcast 不改变比特位，只改解释方式
bitcast 是 LLVM IR 中最“轻量”的类型转换指令：它不做任何数值计算或位宽调整，只是把同一段内存或寄存器内容，用另一种类型重新解读。比如把 i32 当作 float 读，或者把 [4 x i8] 当作 i32 读——源和目标类型必须大小严格相等（@sizeOf 相同），否则编译直接报错：invalid bitcast。
常见误用场景：
- 想把
i16扩展成i32却写了bitcast i16 %x to i32→ 报错，位宽不匹配 - 把
floatbitcast成i32后，再拿结果当整数算术运算 → 语义合法但逻辑危险，容易混淆浮点位模式和整数值 - 对指针用
bitcast改变地址空间（如ptr to addrspace(1)）却没配addrspacecast→ 可能触发后端未定义行为
zext/sext/trunc 是真正的数值转换
zext（零扩展）、sext（符号扩展）、trunc（截断）操作的是数值语义，不是字节解释。它们会生成新值，可能改变位模式（比如 sext i8 -1 to i32 得到 i32 -1，即全 1 的 32 位），且允许位宽变化。
关键约束：
-
zext和sext只能用于**扩大**位宽（如i8 → i16），不能缩小 -
trunc只能用于**缩小**位宽（如i32 → i8），高位直接丢弃 - 对有符号整数做
zext是危险的：比如zext i8 -1 to i16得到0xFF00（即 65280），不是预期的 -1
为什么不能用 bitcast 替代数值转换
根本原因在于 ABI 和优化器对二者处理完全不同。例如：
-
bitcast在 SSA 形式中不引入新计算，LLVM 优化器可能把它折叠、消除，甚至跨基本块重排；而zext明确表示“这里需要一个零扩展值”，优化器会保留其语义边界 - 某些后端（尤其是 GPU 或嵌入式）对
bitcast生成 mov 指令，而zext可能生成 and/or/shl 组合，硬件行为不可互换 - 在函数调用传参时，ABI 要求按类型做实际扩展（如
i8参数传i32寄存器需zext），用bitcast会导致栈/寄存器内容错位
实际写 IR 时怎么选
记住这个判断链：
- 目标类型和源类型**位宽相同**？→ 优先考虑
bitcast（比如 reinterpret float as int for bit-level ops） - 要**扩大位宽**且保持数值含义？→
zext（无符号）或sext（有符号） - 要**缩小位宽**？→
trunc，但务必确认高位可丢弃 - 涉及指针和地址空间？→ 用
ptrtoint/inttoptr+ 算术 +inttoptr，或直接addrspacecast，别碰bitcast
最容易被忽略的一点：LLVM IR 是强类型且面向优化的，bitcast 的“无操作”假象常让人低估它对后续优化路径的影响——它可能让某个值意外逃逸出类型安全边界，尤其在跨函数内联时。
