ARM NEON中基于vld1q递增内存偏移分支为何变慢？

我发现当以vld1q_u16（对应汇编ldr q17, [x17], #16）指令递增的内存地址作为分支判断依据时，ARM NEON代码运行速度慢了约3倍。通过宏定义UNREASONABLY_SLOW_CODE可切换快慢代码路径，测试覆盖AWS Graviton2和Apple M2平台，均呈现3倍性能差距。

NEON核心汇编对比 #

慢循环 #

该循环使用加载指令后自增的内存寄存器x17作为分支判断基准：

.LBB0_4:                                //   Parent Loop BB0_3 Depth=1
-->     ldr     q17, [x17], #16
-->     cmp     x17, x16
        mov     v18.16b, v17.16b
        sli     v17.8h, v17.8h, #5
        sri     v18.8h, v18.8h, #5
        shrn    v0.8b, v17.8h, #2
        sri     v17.8h, v17.8h, #6
        shrn    v2.8b, v18.8h, #8
        shrn    v1.8b, v17.8h, #8
        st4     { v0.8b, v1.8b, v2.8b, v3.8b }, [x18], #32
-->     b.lo    .LBB0_4

快循环 #

该循环使用独立的控制流寄存器x14作为计数器（类似标准C for循环的i）：

.LBB0_5:                                //   Parent Loop BB0_3 Depth=1
        ldr     q17, [x15], #16
-->     add     x14, x14, #8
-->     cmp     x14, x11
        mov     v18.16b, v17.16b
        sli     v17.8h, v17.8h, #5
        sri     v18.8h, v18.8h, #5
        shrn    v0.8b, v17.8h, #2
        sri     v17.8h, v17.8h, #6
        shrn    v2.8b, v18.8h, #8
        shrn    v1.8b, v17.8h, #8
        st4     { v0.8b, v1.8b, v2.8b, v3.8b }, [x16], #32
-->     b.lt    .LBB0_5

性能差异原因分析 #

• 依赖链阻塞流水线：慢循环中，cmp x17, x16必须等待ldr q17, [x17], #16完成并更新x17后才能执行。内存加载操作存在固有延迟，即使命中缓存，也会形成写后读依赖，导致CPU流水线无法乱序执行后续指令，整体吞吐量下降。
• 分支预测效率降低：分支条件依赖内存加载的结果时，CPU分支预测器无法提前确定分支走向，容易出现预测错误。每次错误预测都会触发流水线清空，带来显著的性能开销。
• 寄存器重命名受限：通用寄存器x17同时承担内存指针和分支判断基准的角色，CPU无法通过寄存器重命名隐藏内存访问的延迟，进一步放大了依赖带来的影响。

进一步优化方案 #

• 保留独立控制计数器模式：继续使用快循环的设计，用独立整数寄存器作为循环计数器，避免将内存指针与控制流判断绑定，消除不必要的依赖链。
• 循环展开优化：通过-funroll-loops编译器选项或手动展开循环，减少分支指令的执行频次，同时让CPU并行处理更多向量操作，提升整体吞吐量。
• 优化内存访问：确保输入输出内存地址对齐到16/32字节边界，提升ldr/st4指令的执行效率；使用独立的指针寄存器管理输入输出地址，避免交叉依赖。
• 指令重排隐藏延迟：在不破坏依赖关系的前提下，调整向量操作顺序，让内存加载操作与后续的sli/sri/shrn操作并行执行，隐藏内存访问的延迟。
• 针对性编译器选项：编译时添加-O3 -march=native选项，让clang针对目标平台（Graviton2/M2）生成最优指令序列，充分利用硬件特性。

内容的提问来源于stack exchange，提问作者J. Rehbein