GEP访问数组时第一个索引必须为0，因为@arr或%arr_ptr本身指向整个数组起始地址，需先用0进入数组取首元素，再通过后续索引定位具体元素。
getelementptr 访问数组元素时，第一个索引必须是 0
因为 @arr（全局数组）或 %arr_ptr（指向数组的指针）本身已经是“指向整个数组起始地址”的指针，不是指向某个元素的指针。GEP 要做的是从这个基地址出发，算出第 i 个元素的地址，所以第一步得先“进入数组”，即用索引 0 表示“取整个数组的第 0 个元素”——也就是数组首元素。
常见错误是写成 getelementptr [10 x i32], [10 x i32]* %arr, i32 5，这会报错：LLVM 要求 GEP 的第一个索引必须是 i32 0（或 i64 0），否则类型不匹配。
- 正确写法：
getelementptr [10 x i32], [10 x i32]* %arr, i32 0, i32 5 - 错误写法：
getelementptr [10 x i32], [10 x i32]* %arr, i32 5（缺了0） - 若指针类型是
i32*（比如%ptr = getelementptr ... , i32 0, i32 0得到的），则访问第 5 个元素只需：getelementptr i32, i32* %ptr, i32 5
多维数组的 GEP 索引顺序：从外到内，每个维度都要显式写出
对于 int a[2][3] 这样的二维数组，IR 中类型是 [2 x [3 x i32]]。要取 a[1][2]，GEP 必须按嵌套结构逐层展开：
- 先取第 1 个子数组：
i32 0（进入整个数组）→i32 1（选第 1 个[3 x i32]） - 再取该子数组中第 2 个元素：
i32 0（进入该[3 x i32]）→i32 2（选第 2 个i32） - 完整索引序列：
i32 0, i32 1, i32 0, i32 2
注意中间两个 0 不可省略：第一个 0 是“进数组”，第二个 0 是“进子数组”，它们语义不同，删掉任一个都会导致类型错位或越界计算。
为什么 GEP 不直接支持 a[i] 这种语法？
LLVM IR 是静态单赋值（SSA）形式，且所有内存操作都显式分离：GEP 只算地址，load/store 才真正读写。它不提供类似 C 的“指针算术缩写”，因为：
- GEP 的设计目标是让编译器在编译期完全确定偏移量，避免运行时计算；
- 类型信息必须全程显式参与计算（比如
[10 x i32]和i32*的步长不同），隐式算术会丢失类型上下文； - 对结构体、嵌套数组等复杂类型，只有分步索引才能无歧义地定位成员。
所以你不会看到 getelementptr i32, i32* %p, i32 %i 直接用于数组基址；它只适用于已解引用到元素指针的情况（如 %elem_ptr = getelementptr ... , i32 0, i32 %i 后再用 %elem_ptr）。
容易忽略的兼容性细节：GEP 索引类型必须匹配平台指针宽度
在 64 位目标上，GEP 的整数索引应使用 i64 而非 i32，尤其当数组很大或索引来自计算结果时：
-
getelementptr [1000000 x i8], [1000000 x i8]* %buf, i64 0, i64 %idx✅ -
getelementptr [1000000 x i8], [1000000 x i8]* %buf, i32 0, i32 %idx❌（可能截断，opt 或 llc 报 warning 或 crash）
Clang 默认生成 i64 索引，但手写 IR 时容易沿用 i32 习惯，尤其从 32 位代码迁移过来。检查方式：用 llvm-dis 反汇编 bitcode，或用 llc -march=host 测试是否能成功生成汇编。
