llvm ir中整数类型为in（n为编译期常量位宽），浮点类型为固定名称（如float、double），类型转换需显式指令（zext/sext/trunc/fpext/fptrunc），且load/store/call等操作严格校验类型匹配。
整数类型用 iN 表示，N 是位宽，不是 C 语言的语义别名
LLVM IR 的整数类型不叫 int 或 long，而是严格按位宽写成 i1、i8、i32、i64 这种形式。这里的 N 是常量，必须在编译时确定，比如 i1942652 合法，但不能写 iN（N 是变量）。
常见误用是以为 i32 等价于 C 的 int —— 实际上它只表示“32 位二进制整数”，符号性由后续指令决定（如 sdiv 带符号除，udiv 无符号除）。IR 不区分 signed/unsigned 类型，只靠指令语义区分。
-
i1常用于布尔运算或掩码，不是“bool 类型”，只是 1-bit 整数 -
alloca i32分配一个 32 位整数空间，和 C 的int x;对应，但 IR 层不保证对齐或 ABI 行为 - 超过
i64的大整数（如i1024）在 IR 中完全合法，但后端可能不支持生成对应机器码
浮点类型用固定名称，float 和 double 最常用
IR 的浮点类型不是 f32 或 f64，而是硬编码的几个名字：float（32 位）、double（64 位）、half（16 位）、fp128、x86_fp80 等。其中只有 float 和 double 被绝大多数后端稳定支持。
注意 float 不等于 C 的 float —— 它明确对应 IEEE-754 binary32；同理 double 是 binary64。如果你写 define float @f() { ret float 3.14 }，这个 3.14 会被精确转为 binary32 表示，不是十进制近似。
-
half在 GPU 或 ARM NEON 场景有用，但 x86-64 默认不生成half指令 -
fp128和x86_fp80语义不同：前者是 IEEE binary128，后者是 x87 扩展精度（80-bit 内部寄存器格式），二者不可互换 - IR 不允许自定义浮点位宽，不像整数那样支持任意
N
zext/sext 和 trunc 是整数宽度转换的关键，浮点用 fpext/fptrunc
整数之间转换不能直接赋值，必须显式用扩展或截断指令。例如把 i32 变成 i64，得用 zext i32 %x to i64（零扩展）或 sext i32 %x to i64（符号扩展）；反过来要 trunc i64 %y to i32。
浮点数同理：fpext float %a to double、fptrunc double %b to float。漏掉这些指令会导致类型不匹配错误，比如 add float %x, double %y 直接报错 —— IR 是强类型的，不自动提升。
-
bitcast不能用于整数↔浮点转换（那是 reinterpret，需用uitofp/fmtoui等） -
zext和sext行为差异影响结果：对负数i32 -1，sext得i64 -1，zext得i64 4294967295 - 所有扩展/截断都要求源目标位宽可静态判定，不能用于运行时动态宽度
类型错误通常在 load/store/call 时暴露，不是定义时
IR 允许你写 %x = alloca i32，但真正出错是在你用错类型访问它的时候。比如：
%p = alloca i32 %v = load i64, i32* %p ; 错！类型不匹配：i32* 不能 load 出 i64
或者函数调用签名不一致：
declare i32 @foo(i64) call i32 @foo(i32 42) ; 错！参数类型 i32 ≠ i64
这类错误 llvm-as 会直接拒绝汇编，而不是静默处理。调试时优先检查 load、store、getelementptr 和 call 指令的操作数类型是否与指针/函数签名完全一致。
最容易被忽略的是指针类型嵌套：比如 i32** 和 i32* 差一个星号，load 时若少写一个 * 就会类型爆炸 —— IR 不做指针解引用推导，全靠你写清楚。
