getelementptr仅计算地址不访问内存，结果为指针值；索引语义依赖前序类型，结构体索引须为i32常量，数组索引可变；inbounds声明同分配单元内有效，助优化但越界致UB；布局依LLVM DataLayout，非必然等价C offsetof。
getelementptr 不执行内存访问，只做地址计算；它的结果是“指针值”，不是数据值，也不触发任何读写或越界检查。
getelementptr 的索引顺序和类型依赖关系
每个索引的含义取决于它前面的类型，不是简单地按字节偏移累加。GEP 从第二个参数（基指针）开始，逐层解构类型结构：
- 第一个索引作用于基指针所指向的类型（比如
[10 x i32]或%struct.point），通常为i32 0表示首元素 - 第二个索引作用于第一个索引“抵达”的那个类型：若前一步得到的是数组，则该索引是数组下标；若得到的是结构体，则必须是
i32常量，对应字段序号（从 0 开始） - 后续索引依此类推，但**中间不能出现指针类型**——GEP 要求每一步索引的目标都是复合类型（struct/array/vector），不能是
i32*这类指针
例如：%x_ptr = getelementptr inbounds %struct.point, %struct.point* %p, i32 0, i32 0 中，i32 0（第一个）选中结构体实例本身，i32 0（第二个）选中其第 0 个字段（即 x）。
inbounds 修饰符的实际影响
getelementptr inbounds 并不保证运行时不越界，而是向优化器声明：“这个计算结果一定在同一个分配单元内”。这允许 LLVM 安全地做如下变换：
- 将
inboundsGEP 后接的load优化为load volatile或消除冗余边界检查 - 在指针比较中，把两个
inboundsGEP 结果视为“可排序”（即使它们来自不同 base ptr） - 但一旦实际地址超出分配块（如对
alloca [1 x i32]做gep ..., i32 1），行为未定义（UB），不会 crash，但优化可能产生意外结果
非 inbounds 版本更保守，限制更少，但会阻碍部分优化。日常手写 IR 或 Pass 开发中，只要逻辑上不跨 allocation unit，应优先用 inbounds。
数组 vs 结构体：索引值的合法性差异
类型决定索引能否是变量、是否需为常量：
- 对数组（
[N x i32]）或向量（<n x i32></n>）：索引可用任意整数类型（i32,i64），且可以是非常量（如%i），LLVM 会在运行时计算 - 对结构体（
{i32, i32}）：索引**必须是i32常量**（如i32 1），因为字段偏移在编译期固定，无法动态查表 - 对指针类型（
i32*）：不能直接作为 GEP 的被索引类型——你不能写getelementptr i32*, i32** %pp, i32 1，必须先 load 出i32*再用其他方式算址
典型错误：getelementptr {i32, i32}, {i32, i32}* %s, i32 %idx ——%idx 是变量，但结构体索引不接受变量，会报错 “invalid constant expression”。
GEP 和真实内存布局的关系
GEP 的计算基于 LLVM 的类型布局规则，不一定等于 C 的 offsetof，尤其在 packed struct 或跨平台场景下：
- 默认 struct 字段按自然对齐填充，
getelementptr ..., i32 1对应第二个字段的起始地址，该地址由 LLVM layout engine 算出（可通过DataLayout查询） - 如果 struct 声明为
packed，字段紧挨，GEP 结果才接近 C 的offsetof；否则字段间可能有 padding - 不要假设
getelementptr ..., i32 0, i32 1等价于((char*)ptr) + 4——除非你知道目标 DataLayout 和 struct 是否 packed
真正容易被忽略的是：GEP 的“计算”完全静态，不依赖运行时值，但它依赖模块级的 type definition 和 DataLayout 配置。换一个 TargetMachine，同一段 GEP 可能生成不同 offset 的机器码。
