x86/ARM平台下小数组运算：数据留存寄存器还是写入L1缓存重取？

核心结论 #

若寄存器充足且编译器启用了足够优化（如-O2/-O3级别），5x5的float数组（共25个元素，总占用100字节）完全可以被编译器全程分配到寄存器中，运算期间不会频繁读写L1缓存。但这一结果并非绝对，取决于编译器的优化决策和代码的具体实现方式。

为什么寄存器可以容纳？ #

• x86平台：XMM（128位）寄存器可存4个float，YMM（256位）存8个，ZMM（512位）存16个。仅需3个YMM寄存器即可容纳24个元素，再加1个XMM存剩余1个，完全在寄存器容量范围内。且x86-64的物理寄存器文件通常有数百个，寄存器资源充足。
• ARM平台：NEON（128位）寄存器可存4个float，7个即可覆盖25个元素；ARMv8的SVE架构寄存器更灵活，资源余量更大。
• 25个float的总数据量极小，远低于寄存器文件的总容量，编译器没有理由放弃寄存器分配而选择缓存读写。

哪些情况会导致数组落到缓存？ #

• 优化级别不足：如-O0模式下，编译器为保留调试信息，会强制频繁读写内存，不会做寄存器分配优化。
• 代码写法限制：使用指针间接访问数组元素、将数组传递给未内联的函数、存在复杂控制流导致编译器无法跟踪元素复用关系，都会让编译器无法确定数组可以全程驻留寄存器。
• 编译器启发式决策：极少数情况下，编译器可能认为缓存读写的综合成本更低，但这种概率极低，因为25个float的寄存器占用成本远低于缓存开销。

如何验证行为？ #

• 查看汇编代码（最直接方法）：
  • x86平台：执行gcc -O3 -S your_code.c生成汇编文件，检查数组元素的运算是否仅使用XMM/YMM/ZMM寄存器，无movss (%rax), %xmm0这类从内存读取的指令。若所有操作都在寄存器间完成，说明数组全程驻留寄存器。
  • ARM平台：32位用arm-linux-gnueabihf-gcc -O3 -S your_code.c，64位用aarch64-linux-gnu-gcc -O3 -S your_code.c，查看是否仅用NEON寄存器（如q0-q31）操作元素，无内存访问指令。
• 性能计数器分析：
  • x86平台：用perf stat -e L1-dcache-loads,L1-dcache-load-misses ./your_program统计缓存命中/缺失率。若L1缓存加载次数极少甚至为0，说明数组未从缓存读取。
  • ARM平台：用perf对应事件（如l1d_cache_refill）统计，逻辑与x86一致。
• 手动强制寄存器分配：
  • 利用编译器扩展语法（如x86的register float arr[25] asm("ymm0, ymm1, ymm2, xmm0");）强制将数组绑定到寄存器，验证性能是否与自动优化结果一致。若一致，说明自动优化已实现寄存器驻留。

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