IRBuilder生成指令时类型不匹配最常导致断言失败，如“Type mismatch in add instruction”，因IRBuilder严格校验操作数类型且拒绝隐式转换；需显式用CreateZExt、CreatePtrToInt等方法做类型转换，并确保load、icmp、gep等指令的操作数类型完全匹配签名。
IRBuilder生成指令时类型不匹配的典型错误现象
最常遇到的是 add、icmp、load 等指令报错，比如：LLVM ERROR: Instruction does not dominate all uses! 或更直接的 Assertion failed: (Ty == V->getType() && "Type mismatch in add instruction")。这不是运行时报错，而是在调用 IRBuilder::CreateAdd 等方法时触发断言失败——说明 IRBuilder 在构造指令前就做了强类型校验，且拒绝隐式转换。
必须显式做类型转换的几个关键场景
IRBuilder 不会自动把 i32 转成 i64，也不会把 int* 当作 char* 用。所有操作数类型必须严格匹配目标指令签名。常见需手动转换的情况包括：
-
load指令的操作数是指针类型，但你传入的是Value*（比如getelementptr返回值），必须确保它是指针类型，不能是整数或struct -
CreateICmpEQ(a, b)要求a和b类型完全一致；若一个是i32、另一个是i64，得先用CreateZExt或CreateSExt统一宽度 -
CreateCall传参时，实参类型必须与函数声明中对应形参类型逐位匹配；哪怕只差一个const（在 LLVM IR 中体现为地址空间或只读属性），也会失败 - 对指针做算术（如
gep）时，索引值必须是inttoptr转换后的整数类型，且索引本身也得是i32或i64，不能是i1或float
用 IRBuilder 做类型转换的正确写法
别手写 CastInst 构造器，直接用 IRBuilder 提供的封装方法，它们会自动插入到当前插入点并返回新 Value*：
- 整数位宽扩展：
builder.CreateZExt(val, Type::getInt64Ty(ctx))（零扩展）、builder.CreateSExt(...)（符号扩展） - 截断：
builder.CreateTrunc(val, Type::getInt32Ty(ctx)) - 指针转整数：
builder.CreatePtrToInt(ptr, Type::getInt64Ty(ctx)) - 整数转指针：
builder.CreateIntToPtr(intval, ptr_type)（注意：目标ptr_type必须是合法指针类型，如PointerType::getUnqual(int32_ty)） - 浮点/整数互转：
builder.CreateSIToFP、builder.CreateFPToSI等，注意指定舍入模式和异常行为（默认是ebStrict）
示例：你想把一个 i32 全局变量值加 1 后存回去，但加载出来的是 i32*，load 得到 i32，而 add 需两个 i32 ——这没问题；但如果你误把 load 结果传给 CreateStore 当作指针用，就会立刻崩。
容易被忽略的隐含类型约束
有些类型匹配问题藏得深，比如：
-
getelementptr的第一个索引（base index）必须是i32或i64，但它的类型不是由字面量决定的，而是由你传入的Value*类型决定；builder.getInt32(0)是i32，但ConstantInt::get(..., 0)若没指定类型，可能生成i64，导致 GEP 失败 - 函数参数类型里若有
byval属性，对应实参必须是指针类型，且指向的类型要和byval声明的结构体类型完全一致（包括字段顺序、填充、地址空间） - 使用
CreateInBoundsGEP时，如果 base 指针类型是i32*，但你要访问第 5 个元素，索引必须是i32（而非i64），否则 IRBuilder 会静默截断或触发断言
真正麻烦的不是“不知道要转换”，而是“以为已经对了”。建议每次构造关键指令后，用 inst->dump() 或 module->print(errs(), nullptr) 看一眼 IR，确认操作数类型是否真如你所想——LLVM IR 的文本可读性其实很高，比调试 C++ 对象状态快得多。
