本地数组大小引发LLVM IR未定义行为，求统一IR的优化标志

首先得拆解下你遇到的现象背后的原因：LLVM在优化阶段会根据数组的大小、对齐要求以及代码里的未定义行为（UB）做出不同的内存布局和优化决策——比如大小为2、4的数组刚好能适配通用寄存器的宽度（比如i32、i64），LLVM的**Scalar Replacement of Aggregates (SRA)**优化会直接把这类小数组拆成单个寄存器处理；而大小为3的数组没法完全塞进常规寄存器，只能保留栈上的整体分配，这就导致了IR结构的差异。如果代码里还存在UB（比如数组越界访问），LLVM会基于UB做更激进的不可预测优化，进一步放大这种差异。

要让不同大小数组生成的LLVM IR保持一致，你可以尝试以下几种方案：

1. 禁用Scalar Replacement优化（最精准的方案） #

SRA是导致小数组和非标准大小数组处理差异的核心优化，你可以通过LLVM的命令行参数直接禁用它：

clang -O2 -mllvm -disable-scalar-repl your_code.c -S -emit-llvm

这个参数会强制LLVM把所有数组当作整体的栈分配对象处理，不管大小是3还是4，IR里的数组内存操作逻辑会基本一致，同时还能保留其他大部分优化。

2. 强制统一的内存对齐规则 #

LLVM有时会根据数组大小自动调整对齐策略，你可以用GNU扩展属性强制数组的对齐方式，让不同大小的数组拥有相同的对齐约束：

// 强制数组按4字节对齐，不管实际大小
int arr[3] __attribute__((aligned(4)));

统一的对齐规则会让LLVM对不同大小数组的内存操作逻辑更趋同，减少优化后的IR差异。

3. 禁用所有优化（最稳妥但性能损失大） #

如果不需要任何优化，直接用-O0编译：

clang -O0 your_code.c -S -emit-llvm

这种情况下LLVM会生成最朴素的栈分配IR，所有数组的处理逻辑完全一致，但代价是代码运行性能会大幅下降。

4. 先修复代码中的未定义行为 #

如果你的代码存在UB（比如越界访问数组、使用未初始化的数组元素），LLVM会针对UB做出不可预测的优化决策，这也是不同大小数组IR差异的重要诱因。先修复UB，确保代码符合C标准，再尝试上述优化方案，IR的一致性会更有保障。

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