LLVM IR中结构体成员访问必须先用getelementptr计算地址再load/store，GEP仅做地址计算不访问内存，返回指针类型，首索引恒为0表示进入结构体实例。
LLVM IR里用 getelementptr 计算结构体成员地址
直接“访问”结构体成员在 LLVM IR 中并不存在——它没有类似 C 的 .x 或 ->y 语法。所有成员访问都必须先用 getelementptr（GEP）算出内存地址，再配合 load 或 store 完成读写。这是由 IR 的低层抽象决定的：它只管字节偏移，不管字段名。
常见错误是把 GEP 当成“取值指令”：写 %field = getelementptr ... 后直接拿 %field 当值用，结果类型错（它返回的是指针，不是值），后续 load 失败或优化被破坏。
- GEP 永远不访问内存，只做地址计算；它的返回类型是
ptr（比如i32*），不是i32 - 索引序列中第一个索引固定为
0（访问聚合体本身，不是数组元素），第二个起才是结构体字段序号 - 必须用
inbounds关键字（除非你明确需要绕过边界检查），否则某些 Pass 可能拒绝优化
例如结构体 {i32, i64, float}，要取第二个字段（i64）：
%struct_ptr = alloca {i32, i64, float}
%field2_ptr = getelementptr inbounds {i32, i64, float}, {i32, i64, float}* %struct_ptr, i32 0, i32 1
%val = load i64, i64* %field2_ptr
getelementptr 索引序列为什么从 0 开始？
因为 GEP 的设计语义是“在某个聚合体里导航”，而第一个索引总是定位到聚合体实例本身——即使你操作的是单个结构体变量，也要先“进入”它，再选字段。这和数组不同：对数组 %arr 取第 i 个元素，写法是 getelementptr ..., ..., i32 %i，第一个索引就是 %i；但对结构体，第一个索引必须是 0，表示“这个结构体实例的起始位置”。
容易踩的坑：
- 误写
getelementptr ..., ..., i32 1想跳过第一个字段 → 实际跳过了整个结构体，指向了非法地址 - 结构体嵌套时漏掉某层的
0，比如{ {i32} , i64 }中取内层i32，必须写i32 0, i32 0, i32 0（外结构体、内结构体、字段） - 用常量整数索引没问题，但若字段序号来自运行时计算（如 switch 分支动态选字段），GEP 不支持；得用其他方式（如 byte offset +
gepwithi8*）
结构体字段顺序依赖 target datalayout
IR 里结构体类型只写 {i32, i64, float}，但字段在内存中真实偏移由模块头部的 target datalayout 决定。比如 e-m:e-p270:32:32-... 中的对齐规则会插入填充字节，i32 后跟 i64 很可能补 4 字节对齐。GEP 指令内部已隐含处理这些布局细节，所以你不需要手动算偏移——但必须确保整个 Module 的 target datalayout 和目标平台一致。
典型问题：
- 跨平台生成 IR 时硬编码了某平台的偏移（比如 x86_64 的
i64对齐为 8），拿到 ARM64 上跑就崩溃 - 手写 IR 时省略
target datalayout，LLVM 默认用 host 平台 layout，导致交叉编译失败 - 结构体含
packed属性（如%S = type）时，GEP 行为仍按 packed layout 算，但调试器或后端可能不完全支持
别用 bitcast 替代 GEP 访问结构体字段
有人试图绕过 GEP，把结构体指针 bitcast 成字节数组或字段类型指针，再加常量偏移——这在 IR 里是未定义行为（UB）。LLVM 不保证结构体字段连续无填充，bitcast 后的指针可能指向填充区，load 触发 poison 值或被优化掉。
正确做法只有一条：严格用 getelementptr 导航，让 LLVM 根据当前 target datalayout 和类型信息推导合法地址。哪怕你觉得“肯定没 padding”，也不要赌。
最后一句提醒：GEP 的索引是常量还是运行时值，会影响能否做常量折叠和死代码消除——如果字段索引是变量，很多基于字段的优化（如结构体拆分、字段提升）就失效了。
