为什么使用 -O3 的 gcc 会不必要地清除本地 ARM NEON 数组？

Question

考虑以下代码（编译器资源管理器链接），在 gcc 和 clang 下编译并进行-O3优化：

#include <arm_neon.h>

void bug(int8_t *out, const int8_t *in) {
    for (int i = 0; i < 2; i++) {
        int8x16x4_t x;

        x.val[0] = vld1q_s8(&in[16 * i]);
        x.val[1] = x.val[2] = x.val[3] = vshrq_n_s8(x.val[0], 7);

        vst4q_s8(&out[64 * i], x);
    }
}

注意：这是一个问题的最小可重现版本，该问题出现在我实际的、更复杂的代码的许多不同函数中，其中充满了执行与上面完全不同的操作的算术/逻辑/排列指令。请不要批评和/或建议执行上述代码的不同方法，除非它对下面讨论的代码生成问题有影响。

clang 生成正常的代码：

bug(signed char*, signed char const*):                            // @bug(signed char*, signed char const*)
        ldr     q0, [x1]
        sshr    v1.16b, v0.16b, #7
        mov     v2.16b, v1.16b
        mov     v3.16b, v1.16b
        st4     { v0.16b, v1.16b, v2.16b, v3.16b }, [x0], #64
        ldr     q0, [x1, #16]
        sshr    v1.16b, v0.16b, #7
        mov     v2.16b, v1.16b
        mov     v3.16b, v1.16b
        st4     { v0.16b, v1.16b, v2.16b, v3.16b }, [x0]
        ret

至于gcc，它插入了很多不必要的操作，显然将最终输入指令的寄存器清零st4：

bug(signed char*, signed char const*):
        sub     sp, sp, #128
        # mov     x9, 0
        # mov     x8, 0
        # mov     x7, 0
        # mov     x6, 0
        # mov     x5, 0
        # mov     x4, 0
        # mov     x3, 0
        # stp     x9, x8, [sp]
        # mov     x2, 0
        # stp     x7, x6, [sp, 16]
        # stp     x5, x4, [sp, 32]
        # str     x3, [sp, 48]
        ldr     q0, [x1]
        # stp     x2, x9, [sp, 56]
        # stp     x8, x7, [sp, 72]
        sshr    v4.16b, v0.16b, 7
        # str     q0, [sp]
        # ld1     {v0.16b - v3.16b}, [sp]
        # stp     x6, x5, [sp, 88]
        mov     v1.16b, v4.16b
        # stp     x4, x3, [sp, 104]
        mov     v2.16b, v4.16b
        # str     x2, [sp, 120]
        mov     v3.16b, v4.16b
        st4     {v0.16b - v3.16b}, [x0], 64
        ### ldr     q4, [x1, 16]
        ### add     x1, sp, 64
        ### str     q4, [sp, 64]
        sshr    v4.16b, v4.16b, 7
        ### ld1     {v0.16b - v3.16b}, [x1]
        mov     v1.16b, v4.16b
        mov     v2.16b, v4.16b
        mov     v3.16b, v4.16b
        st4     {v0.16b - v3.16b}, [x0]
        add     sp, sp, 128
        ret

我手动添加了#所有可以安全取出的指令前缀，而不会影响函数的结果。

此外，以 为前缀的指令###执行不必要的内存往返行程（无论如何，后面mov的指令### ld1 ...会覆盖该指令加载的 4 个寄存器中的 3 个ld1），并且可以直接替换为单个加载v0.16b- 并且sshr指令然后块的中间将用作v0.16b其源寄存器。

据我所知，x是局部变量，可以统一使用；即使不是，所有寄存器都已正确初始化，因此将它们清零以立即用值覆盖它们是没有意义的。

我倾向于认为这是一个 gcc bug，但在报告之前，我很好奇我是否错过了一些东西。也许有一个编译标志，一个__attribute__或其他东西我可以用来gcc生成健全的代码。

因此，我的问题是：我可以做些什么来生成正常的代码，还是这是一个我需要向 gcc 报告的错误？

Answer 1

相当当前的 gcc 开发版本上的代码生成似乎已经有了很大的改进，至少在这种情况下是这样。

安装该gcc-snapshot软件包（日期为 20210918）后，gcc 生成以下代码：

bug:
        ldr     q5, [x1]
        sshr    v4.16b, v5.16b, 7
        mov     v0.16b, v5.16b
        mov     v1.16b, v4.16b
        mov     v2.16b, v4.16b
        mov     v3.16b, v4.16b
        st4     {v0.16b - v3.16b}, [x0], 64
        ldr     q4, [x1, 16]
        mov     v0.16b, v4.16b
        sshr    v4.16b, v4.16b, 7
        mov     v1.16b, v4.16b
        mov     v2.16b, v4.16b
        mov     v3.16b, v4.16b
        st4     {v0.16b - v3.16b}, [x0]
        ret

尚不理想——通过更改和 的mov目标寄存器，每次迭代至少可以删除两条指令，但比以前好得多。ldrsshr