如何阻止 GCC 破坏我的 NEON 内在函数? [英] How to stop GCC from breaking my NEON intrinsics?

问题描述

我需要为一个项目编写优化的 NEON 代码，我非常乐意编写汇编语言，但为了可移植性/可维护性，我正在使用 NEON 内在函数.这段代码需要尽可能快，所以我利用我在 ARM 优化方面的经验来正确交错指令并避免管道停顿.无论我做什么，GCC 都会对我不利，并创建充满停顿的较慢代码.

有谁知道如何让 GCC 摆脱困境并将我的内在函数转换为代码?

这是一个例子:我有一个简单的循环，它否定和复制浮点值.它一次处理 4 组 4 组，以留出一些时间来加载内存和执行指令.剩下的寄存器很多，所以没有理由把事情搞得这么糟糕.

float32x4_t f32_0, f32_1, f32_2, f32_3;整数 x;对于 (x=0; x

这是它生成的代码:

vld1.32 {d18-d19}, [r5]vneg.f32 q9,q9 <-- GCC 故意导致停顿添加 r7,r7,#16vld1.32 {d22-d23}, [r8]添加 r5,r1,r4vneg.f32 q11,q11 <-- 我所有的交错都被撤销了(为什么?！！?)添加 r8,r3,#256vld1.32 {d20-d21}, [r10]添加 r4,r1,r3vneg.f32 q10,q10添加 lr,r1,lrvld1.32 {d16-d17}, [r9]添加ip,r1,ipvneg.f32 q8,q8

更多信息:

• 适用于 Raspbian 的 GCC 4.9.2
• 编译器标志:-c -fPIE -march=armv7-a -Wall -O3 -mfloat-abi=hard -mfpu=neon

当我在 ASM 代码中完全按照我的内在模式编写循环时(甚至不使用额外的 src/dest 寄存器来获得一些空闲的 ARM 周期)，它仍然比 GCC 的代码快.

更新:我很欣赏 James 的回答，但在事情的方案中，它并没有真正帮助解决问题.使用 cortex-a7 选项时，我的最简单的函数的性能要好一些，但大多数没有看到任何变化.可悲的事实是 GCC 对内在函数的优化并不是很好.几年前，当我使用 Microsoft ARM 编译器时，它始终为 NEON 内在函数创建精心设计的输出，而 GCC 始终如一.使用 GCC 4.9.x，没有任何改变.我当然欣赏 GCC 的 FOSS 性质和更大的 GNU 努力，但不可否认，它不如 Intel、Microsoft 甚至 ARM 的编译器做得好.

解决方案

从广义上讲，您在此处看到的优化类称为指令调度".GCC 使用指令调度来尝试为程序的每个基本块中的指令构建更好的调度.这里，调度"是指块中指令的任何正确排序，更好"的调度可能是避免停顿和其他管道危险的调度，或者减少变量的有效范围(导致更好的寄存器分配))，或说明中的其他一些排序目标.

为了避免由于危险而导致停顿，GCC 使用了您所针对的处理器的管道模型(请参阅 此处 了解用于这些的规范语言的详细信息，以及此处 为示例管道模型).该模型对处理器功能单元的 GCC 调度算法以及这些功能单元上指令的执行特性给出了一些指示.然后，GCC 可以调度指令以最大程度地减少由于多条指令需要相同的处理器资源而造成的结构性危害.

没有 -mcpu 或 -mtune 选项(编译器)，或 --with-cpu 或 --with-tune 选项(用于编译器的配置)，ARM 或 AArch64 的 GCC 将尝试使用您所针对的架构修订版的代表性模型.在这种情况下，-march=armv7-a 会导致编译器尝试调度指令，就像 -mtune=cortex-a8 在命令行上传递一样.>

因此，您在输出中看到的是 GCC 尝试将您的输入转换为它期望在 Cortex-A8 上运行时能很好地执行的计划，并在实现 ARMv7-A 架构的处理器上运行得相当好.

要对此进行改进，您可以尝试:

• 明确设置您的目标处理器 (-mcpu=cortex-a7)
• 完全禁用指令调度 (`-fno-schedule-insns -fno-schedule-insns2)

请注意，完全禁用指令调度很可能会导致您在其他地方出现问题，因为 GCC 将不再尝试减少代码中的管道风险.

编辑 关于您的编辑，GCC 中的性能错误可以在 GCC Bugzilla 中报告(参见 https://gcc.gnu.org/bugs/ )就像正确性错误一样.当然，所有优化都涉及一定程度的启发式，编译器可能无法击败经验丰富的汇编程序员，但如果编译器正在做一些特别令人震惊的事情，则值得强调.

I need to write optimized NEON code for a project and I'm perfectly happy to write assembly language, but for portability/maintainability I'm using NEON instrinsics. This code needs to be as fast as possible, so I'm using my experience in ARM optimization to properly interleave instructions and avoid pipe stalls. No matter what I do, GCC works against me and creates slower code full of stalls.

Does anyone know how to have GCC get out of the way and just translate my intrinsics into code?

Here's an example: I have a simple loop which negates and copies floating point values. It works with 4 sets of 4 at a time to allow some time for the memory to load and instructions to execute. There are plenty of registers left over, so it's got no reason to mangle things so badly.

float32x4_t f32_0, f32_1, f32_2, f32_3;
int x;
for (x=0; x<n-15; x+=16)
{
   f32_0 = vld1q_f32(&s[x]);
   f32_1 = vld1q_f32(&s[x+4]);
   f32_2 = vld1q_f32(&s[x+8]);
   f32_3 = vld1q_f32(&s[x+12]);
   __builtin_prefetch(&s[x+64]);
   f32_0 = vnegq_f32(f32_0);
   f32_1 = vnegq_f32(f32_1);
   f32_2 = vnegq_f32(f32_2);
   f32_3 = vnegq_f32(f32_3);
   vst1q_f32(&d[x], f32_0);
   vst1q_f32(&d[x+4], f32_1);
   vst1q_f32(&d[x+8], f32_2);
   vst1q_f32(&d[x+12], f32_3);
} 

This is the code it generates:

vld1.32 {d18-d19}, [r5]
vneg.f32  q9,q9        <-- GCC intentionally causes stalls
add r7,r7,#16
vld1.32 {d22-d23}, [r8]
add r5,r1,r4
vneg.f32 q11,q11   <-- all of my interleaving is undone (why?!!?)
add r8,r3,#256
vld1.32 {d20-d21}, [r10]
add r4,r1,r3
vneg.f32 q10,q10
add lr,r1,lr
vld1.32 {d16-d17}, [r9]
add ip,r1,ip
vneg.f32 q8,q8

More info:

• GCC 4.9.2 for Raspbian
• compiler flags: -c -fPIE -march=armv7-a -Wall -O3 -mfloat-abi=hard -mfpu=neon

When I write the loop in ASM code patterned exactly as my intrinsics (without even making use of extra src/dest registers to gain some free ARM cycles), it's still faster than GCC's code.

Update: I appreciate James' answer, but in the scheme of things, it doesn't really help with the problem. The simplest of my functions perform a little better with the cortex-a7 option, but the majority saw no change. The sad truth is that GCC's optimization of intrinsics is not great. When I worked with the Microsoft ARM compiler a few years ago, it consistently created well crafted output for NEON intrinsics while GCC consistently stumbled. With GCC 4.9.x, nothing has changed. I certainly appreciate the FOSS nature of GCC and the greater GNU effort, but there is no denying that it doesn't do as good a job as Intel, Microsoft or even ARM's compilers.

解决方案

Broadly, the class of optimisation you are seeing here is known as "instruction scheduling". GCC uses instruction scheduling to try to build a better schedule for the instructions in each basic block of your program. Here, a "schedule" refers to any correct ordering of the instructions in a block, and a "better" schedule might be one which avoids stalls and other pipeline hazards, or one which reduces the live range of variables (resulting in better register allocation), or some other ordering goal on the instructions.

To avoid stalls due to hazards, GCC uses a model of the pipeline of the processor you are targeting (see here for details of the specification language used for these, and here for an example pipeline model). This model gives some indication to the GCC scheduling algorithms of the functional units of a processor, and the execution characteristics of instructions on those functional units. GCC can then schedule instructions to minimise structural hazards due to multiple instructions requiring the same processor resources.

Without a -mcpu or -mtune option (to the compiler), or a --with-cpu, or --with-tune option (to the configuration of the compiler), GCC for ARM or AArch64 will try to use a representative model for the architecture revision you are targeting. In this case, -march=armv7-a, causes the compiler to try to schedule instructions as if -mtune=cortex-a8 were passed on the command line.

So what you are seeing in your output is GCC's attempt at transforming your input in to a schedule it expects to execute well when running on a Cortex-A8, and to run reasonably well on processors which implement the ARMv7-A architecture.

To improve on this you can try:

• Explicitly setting the processor you are targeting (-mcpu=cortex-a7)
• Disabling instruction scheduling entirely (`-fno-schedule-insns -fno-schedule-insns2)

Note that disabling instruction scheduling entirely may well cause you problems elsewhere, as GCC will no longer be trying to reduce pipeline hazards across your code.

Edit With regards to your edit, performance bugs in GCC can be reported in the GCC Bugzilla (see https://gcc.gnu.org/bugs/ ) just as correctness bugs can be. Naturally with all optimisations there is some degree of heuristic involved and a compiler may not be able to beat a seasoned assembly programmer, but if the compiler is doing something especially egregious it can be worth highlighting.

这篇关于如何阻止 GCC 破坏我的 NEON 内在函数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！