GCC实现可变长数组VLA时为何汇编代码中出现22、15这类特殊常量？

首先需要说明，你提供的C代码使用了GCC扩展的变长数组（VLA）特性，不属于标准C的语法范畴，这类数组的空间是在栈上动态分配的，所以会涉及到动态调整栈指针的逻辑。

核心结论 #

这两个常量都不是随机设定的，本质是不同版本GCC在实现变长数组栈空间分配时，为了满足x86-64 System V ABI的栈对齐规则，所产生的实现差异。

1. 对齐规则的基础要求 #

x86-64 System V ABI明确要求：任意函数调用前，栈指针%rsp必须对齐到16字节边界。你的代码中vals是元素为8字节long的变长数组，总大小为8 * n字节，分配这块空间后必须保证%rsp仍保持16字节对齐，否则后续call read_val()会触发对齐异常。
对数值向上取整到最近的16倍数的通用公式是：(目标值 + 15) & -16，其中-16等价于~0xf，作用是清除数值的低4位。

2. GCC 5.4 中22的来源 #

你观察到的8*%rax + 22再和-16与的结果，确实和8*%rax + 16再与-16的结果完全一致。选择22而非更直观的16，是GCC 5.4版本内部栈布局计算的冗余导致的：

• 当时GCC的栈分配逻辑在计算VLA所需空间时，会额外加入固定的偏移量，用于预留栈保护（stack protector）、临时变量等潜在的空间需求
• 这些预留空间在你的代码场景下被优化掉了，但计算常量的时候没有同步修正，最终保留了无实际作用的额外6字节偏移（22=16+6），由于6小于16，向上取整的结果不受影响，不会导致功能错误。

3. GCC 11.2 中15的来源 #

GCC 11对栈分配算法做了优化，移除了不必要的冗余偏移，直接使用了标准的向上取整公式：
leaq 15(,%rax,8), %rax 就是直接对应(8*n + 15)，再和-16与就能得到刚好满足对齐要求的最小分配大小，没有多余的空间浪费，也更符合直觉。

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