为何相同C结构体类型使用clang编译时会被转换为两种不同的LLVM IR类型

你观察到的现象和编译优化完全无关，是你所用目标平台（大概率是x86_64架构的System V ABI环境，比如Linux、macOS）的C++调用约定强制要求的：

• 内存中存储的结构体对象（包括指针指向的对象、栈上alloca的对象）必须严格遵守定义的内存布局，保证字段偏移正确，所以类型永远是%struct.vec3 = type { i32, i32, i32 }
• 当结构体按值传递给函数、或者作为函数返回值返回时，ABI会判断该结构体的大小、字段类型是否符合寄存器传递的条件：你这个vec3总大小12字节，仅包含普通整数字段，符合小结构体寄存器传递的要求，因此ABI规定将其拆分为两个部分传递：前8字节（x、y两个4字节字段拼接）存入第一个64位通用寄存器，剩下4字节的z字段存入第二个通用寄存器，对应到LLVM IR中就会用{ i64, i32 }类型表示这个按值传递的结构体。

你需要在Pass中主动区分两种上下文的结构体类型，按需做转换：

• 如果需要把内存中存储的%struct.vec3对象转为按值传递的{ i64, i32 }：可以通过指针偏移分别读取对应位置的字节拼接，或者用bitcast+load组合实现。
• 如果需要把函数返回的{ i64, i32 }值写入内存的%struct.vec3对象：可以用extractvalue分别取出两个成员，拆分第一个i64为两个i32后，按偏移写入结构体对应的字段位置。
  如果你的Pass需要跨架构兼容，建议直接复用Clang的ABI相关接口获取结构体的拆分规则，避免自己硬编码判断。

这种设计是为了性能优化：小结构体通过寄存器传递的效率远高于栈内存传递，属于平台级的约定，所有符合该ABI的编译器都会生成同样逻辑的代码，不是LLVM的特殊行为。

内容的提问来源于stack exchange，提问作者Ivanov