嵌入式性能优化：深度解析ARM VFMA指令的生成与实战

1. 项目概述

1.1 核心需求解析

做嵌入式开发的工程师，尤其是长期跟ARM Cortex-A系列、DSP或者带FPU的MCU打交道的朋友，应该都听过“融合乘加”这个词。简单说就是一条指令同时完成加法和乘法，把a*b+c这个两步操作合并成一次运算。标题里提到的 VFMA，全称是 Vector Fused Multiply Add，是 ARM 指令集中专门用来做向量融合乘加的一类指令。

有些朋友可能会问，编译器不是会自动优化吗？还要手动去管它？实测下来真不是那么回事。不同编译器、不同优化等级、甚至同一个编译器不同版本，生成的代码差别都很大。尤其是跑算法类的代码（比如矩阵运算、FIR滤波器、卷积神经网络的推理），数据量一大，一条指令的区别在循环里被放大几百万次，性能差距就非常可观了。

这篇内容适合正在做嵌入式性能优化的朋友，不管你是用 GCC 交叉编译链的 Linux 嵌入式方向，还是用 ARMCC/AC6 做 MCU 开发的方向，核心思路是共通的。我会从编译选项的配置、代码层面的配合写法、以及如何确认编译器真的生成了 VFMA 指令这几个角度展开，最后把实际踩过的坑和排查方法分享出来。

1.2 为什么要关注 VFMA 指令

先说一个直观的数据。在常见的 Cortex-M7 上，如果是硬件单精度 FPU，一条 VFMA 指令大约能在 3 个周期内完成乘加。而如果编译器生成的是 VMLA（逐条乘法再加法），或者更糟糕的情况——生成两条独立指令（一条 VADD、一条 VMUL），那就是 4 到 6 个周期。看起来每个循环只差两三个周期，但一个 FIR 滤波器动辄跑几千个采样点，一秒钟几十万次采样，累积起来就是毫秒级甚至更大的差距。

在嵌入式系统里，时间就是硬实时约束。控制周期 1kHz 的电机控制，电流环计算要是能省下几微秒，整个环路稳定性就有了更大的余量。音频处理里的卷积混响，ARM Cortex-A 系列上用 NEON 优化，融合乘加与否直接决定了能不能达到实时性要求。所以说，去让编译器生成 VFMA 不是强迫症，而是实打实的性能需求。

1.3 适用场景分析

VFMA 指令并不是万能的，它在以下场景中收益最明显：

• 数字信号处理类算法：FIR/IIR 滤波器、FFT 蝶形运算、卷积操作，这些算法天然就是大量的乘加运算堆叠。
• 矩阵运算与线性代数：矩阵乘法、矩阵求逆中的高斯消元，核心操作也是乘加。
• 神经网络推理：嵌入式端的 CNN 推理，卷积层的本质就是乘加累加，融合乘加可以显著减少指令数量。
• 控制算法：PID 升级为增量式 PID 时，计算量大了不少，融合乘加对执行周期的压缩有正向帮助。
• 图形处理与坐标变换：图形旋转矩阵、透视变换等都需要大量浮点运算。

2. 编译器如何决定是否生成 VFMA

2.1 指令生成的内在逻辑

编译器什么时候会把乘法和加法合并成一条 FMA 指令？关键在于编译器选项里是否允许这种“重新关联”操作。浮点运算是讲究精确度的，a*b+c和fma(a,b,c)的中间结果精度不同——前者先算乘法，结果可能是舍入过的；后者直接在完整精度上做乘加，只在最后舍入一次。编译器默认会严格遵守 IEEE 754 浮点标准，也就是保持运算顺序不变，所以不额外开启选项的话，它是不会主动生成 FMA 指令的。

它背后的逻辑叫浮点运算的快速模式（fast-math）。开启这个模式后，编译器不再保证每个中间步骤都严格舍入，换来的是它可以把多条浮点运算重新组合、关联，从而生成更高效的指令。VS 编译器里有/fp:fast，GCC 里有-ffast-math，ARMCC 里有--fpmode=fast，本质上都是同一回事。

不过这里有坑。开了 fast-math 之后，不是所有的浮点计算都仍保持你预期的行为。比如if (x == x)检测 NaN 的代码可能会被优化掉，因为编译器认为相等性永远成立；再比如x + 0.0可能被优化成x，但如果 x 是负数零就出问题了。所以开这个选项之前，要对代码里的浮点行为有一定的把握。

2.2 GCC 与 ARM Compiler 的选项对比

嵌入式开发常用的是两条工具链：GCC（包括 arm-none-eabi-gcc 和 aarch64-linux-gnu-gcc）和 ARM Compiler（包括老的 armcc 和新的 armclang/AC6）。

GCC 这边的核心选项是：

-ffp-contract=fast // 允许生成融合乘加 -ffast-math // 更激进的浮点优化，包含 -ffp-contract=fast

ARM Compiler 5（armcc）这边：

--fpmode=fast // 开启快速浮点模式 --fpu=neon // 指定 FPU 类型，Cortex-A 系列需要

ARM Compiler 6（armclang）的用法跟 Clang 保持一致，和 GCC 类似：

-ffp-contract=fast -O2 或 -O3

用 Keil MDK 做开发的朋友要注意：MDK 自带的 AC6 编译器，工程配置里 Optimization 下拉框选择-O3 -ffp-contract=fast，但实际能否生效还要看编译器版本。我踩过坑：某个旧版 AC6 下-ffp-contract=fast不生效，必须手动敲-ffast-math才行。

2.3 汇编输出级别的确认方法

很多时候你以为开了选项就完了，实际上编译器可能没按你想的去做。每次改完编译选项，建议反汇编确认真正生成的指令。GCC 的用法：

arm-none-eabi-objdump -d your_elf_file.elf > disassembly.txt

也可以在编译时加上-S参数，直接生成汇编文件：

arm-none-eabi-gcc -O3 -ffp-contract=fast -mfpu=fpv5-d16 -mfloat-abi=hard -S main.c -o main.s

生成的汇编文件里搜索vfma或者fmla（NEON 下的融合乘加指令变种）：

grep -n "vfma\|fmla" main.s

如果能搜到，说明编译器确实生成了融合乘加指令；搜不到的话，就要排查是编译器版本的问题，还是代码结构的问题，抑或是 FPU 指令集参数没配对。

需要注意的是，AArch64 架构下的指令名跟 ARMv7 有些区别。Cortex-A53 这类 64 位处理器上，浮点乘加指令是fmadd（标量）和fmla（向量），而 ARMv7 的 NEON 下是vfma。命名不同，但性能收益类似。当你交叉编译一个 ARMv8 的程序时，搜索关键词要换成fmla或fmadd，别死盯着vfma搜。

3. 代码层面的配合手法

3.1 循环结构的编排

编译器在优化循环时，能不能生成 VFMA 很大程度上取决于代码结构是否清晰。最核心的一点是：让乘加操作出现在同一个表达式里，并且不要插入额外的赋值操作。

看一个优化前的示例：

// 性能较差的写法 float acc = 0.0f; for (int i = 0; i < N; i++) { float p = input[i] * coeff[i]; // 先算乘积，存到临时变量 acc += p; // 再做累加 }

这个写法在编译优化时，不一定会被合并成 FMA，因为中间变量p生成了一条独立的 VMUL 指令。更好的写法是直接写成乘加表达式的形式：

// 推荐写法 float acc = 0.0f; for (int i = 0; i < N; i++) { acc += input[i] * coeff[i]; // 一步到位 }

这种写法在语义层面就明确表达了“乘加”的意图，编译器在-ffp-contract=fast下合并的概率会高很多。

再进一步，如果要处理的是复数乘法或者矩阵乘法的内层循环，建议把内层循环拆成多个累加器。比如：

// 使用多个累加器，减少循环依赖 float acc0 = 0.0f, acc1 = 0.0f, acc2 = 0.0f, acc3 = 0.0f; for (int i = 0; i < N; i += 4) { acc0 += input[i] * coeff[i]; acc1 += input[i + 1] * coeff[i + 1]; acc2 += input[i + 2] * coeff[i + 2]; acc3 += input[i + 3] * coeff[i + 3]; } float acc = (acc0 + acc1) + (acc2 + acc3);

这样写的好处是让处理器的流水线能够并行执行多条独立的 FMA 操作。现代 ARM 处理器通常有多个浮点执行单元，如果只有一个累加器，每步操作都有数据依赖，流水线会被卡住；拆成四个累加器后，四条链可以并行推进，吞吐量直接上一个台阶。

3.2 编译器的活着学（restrict 关键字）

另一个容易忽略的点是指针别名问题。C 语言的指针很自由，编译器没法确定两个指针是否指向同一片内存。看看这段代码：

void process_data(float *output, const float *input, float *coeff, int n) { for (int i = 0; i < n; i++) { output[i] = output[i] + input[i] * coeff[i]; } }

编译器看到output和input两个指针，不能确定它们是否指向同一块地址。如果指向了同一块区域，那么写output[i]就会影响后面循环中读input[i]的值，编译器就不敢大胆地做循环展开和指令重排。解决办法是用 C99 的restrict关键字：

void process_data(float *restrict output, const float *restrict input, const float *restrict coeff, int n) { for (int i = 0; i < n; i++) { output[i] = output[i] + input[i] * coeff[i]; } }

restrict告诉编译器：这几个指针指向的区域互不重叠，你可以放心大胆地优化。对于生成 FMA 指令来说，这个关键字虽然不直接触发 VFMA，但它消除了编译器的一个“担忧”，让它更愿意做激进的循环变换，间接为生成 VFMA 创造了条件。

3.3 使用内建函数直接规避编译器

如果编译器始终不生成 VFMA，还有一个更直接的方式——使用编译器内建的 FMA 函数，绕开编译器的自动决策。ARM 编译器提供了__fmaf（单精度）和__fma（双精度）的内建函数。GCC 的写法是：

#include <math.h> float result = fmaf(a, b, c);

这种情况下，编译器会直接生成对应的 FMA 指令，不需要依赖任何 fast-math 选项。代价是如果开启了-ffp-contract=fast，fmaf函数调用会被内联为一条指令；如果没开的话，它可能被解析为函数调用，从性能角度看就有开销了。嵌入式上一般建议两个手段同时用：开 fast 选项 + 关键热点代码用fmaf显式声明。

NEON 内建函数也有对应的版本，vmlaq_f32就是做向量乘加的，但它生成的是 VMLA 还是 VFMA 取决于编译选项。在 GCC 下，如果启用了-ffp-contract=fast，内建函数会被进一步优化为 VFMA。所以写法上建议直接用乘加表达式，让编译器去挑指令，比死板的 NEON intrinsic 更灵活。

4. 实操过程与核心环节实现

4.1 实操环境的搭建

我用的是两个环境做对照实验：

• 环境A：ARM Cortex-M7 开发板（STM32H743），arm-none-eabi-gcc 10.3.1 交叉编译。
• 环境B：ARM Cortex-A53 的单板（树莓派 3B 跑裸机测试程序），aarch64-linux-gnu-gcc 10.2.0 编译。

为了把“编译器是否生成 VFMA”对性能的影响独立出来，先写一个简单的 FIR 滤波器程序作为基准测试。

#define TAPS 64 #define BLOCK_SIZE 256 float fir_baseline(float *input, float *coeff, float *history, float *output) { for (int n = 0; n < BLOCK_SIZE; n++) { history[0] = input[n]; float acc = 0.0f; for (int k = 0; k < TAPS; k++) { acc += history[k] * coeff[k]; // 这是核心乘加操作 } output[n] = acc; // 把 history 里的数据往后移一位，为下一次做准备 for (int k = TAPS - 1; k > 0; k--) { history[k] = history[k - 1]; } } }

实际测试时，直接对比以下几种编译方式的耗时：

• 普通-O2，不开任何浮点优化选项。
• 开启-O3 -ffp-contract=fast。
• 开启-O3 -ffast-math。

4.2 编译与反汇编分析

M7 环境上的编译命令：

arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -O3 -ffp-contract=fast -S fir.c -o fir_contract_fast.s

打开生成的汇编文件，定位到 FIR 核心循环：

grep -n "vfma\|vmla\|vadd\|vmul" fir_contract_fast.s

正常开启-ffp-contract=fast后，你会看到类似这样的汇编内容：

.L4: vldr.32 s14, [r0, r3] @ 加载 input vldr.32 s15, [r1, r3] @ 加载 coeff vfma.f32 s13, s15, s14 @ 这就是我们要的融合乘加 adds r3, r3, #4 cmp r3, #256 bne .L4

注意看vfma.f32 s13, s15, s14，它的语义是s13 += s15 * s14，一条指令搞定了乘和加。再看不开启浮点优化时的汇编：

.L4: vldr.32 s14, [r0, r3] vldr.32 s15, [r1, r3] vmul.f32 s14, s15, s14 @ 先算乘法 vadd.f32 s13, s13, s14 @ 再算加法 adds r3, r3, #4 cmp r3, #256 bne .L4

这里生成了vmul和vadd两条指令。单次循环看起来只差一条指令，但 256 个采样点乘以 64 阶滤波器，整个处理流程就是 16384 次乘加，差了 16384 条指令。在 400MHz 的 M7 上，这个差距是可以实实在在测量出来的。

4.3 AArch64 环境的验证

AArch64（Cortex-A53 上）的验证方式类似。编译命令换成：

aarch64-linux-gnu-gcc -O3 -ffp-contract=fast -S fir.c -o fir_a53.s

反汇编后搜索关键词也要换：

grep -n "fmadd\|fmla" fir_a53.s

AArch64 下的标量融合乘加指令是fmadd d0, d1, d2, d3，含义是d0 = d1 * d2 + d3，注意操作数顺序跟 ARMv7 有点不一样，但核心是一样的。向量版本是fmla v0.4s, v1.4s, v2.4s，含义是v0 += v1 * v2，这个更接近 NEON 的 VFMA。

性能测试结果很直观：A53 上开启融合乘加之后，FIR 处理的总耗时大约能下降 15% 到 20%。因为 A53 是双发射、顺序执行的乱序核心，指令数减少对总时间的压缩效果特别明显。

4.4 实测性能数据对比

把三个版本的性能数据整理对比一下（基于 400MHz 的 STM32H743，处理 1024 个采样点、64 阶 FIR 滤波器）：

从数据上可以清楚看到，单纯开启-ffp-contract=fast的收益是立竿见影的，而-ffast-math在融合乘加之外，还会帮助编译器做循环展开和向量化，效果更好，但风险也更大。

注意：这里的耗时数据是我在特定环境下的实测结果，不代表所有环境都这样。MCU 型号、编译器版本、优化参数、代码结构都会影响具体数字，但方向是一致且明确的。

4.5 自动向量化的结合使用

GCC 还有一个相关选项叫自动向量化，-O3级别下默认开启。它的作用是把标量循环转换成 NEON/SIMD 向量指令。如果向量化和融合乘加叠加使用，效果是相乘的。

以 Cortex-A53 为例，开启-O3 -ffp-contract=fast后，编译器可能会生成这样的 AArch64 NEON 代码：

.L4: ldr q0, [x0, x3] ldr q1, [x1, x3] fmla v2.4s, v0.4s, v1.4s @ 四个数同时乘加 add x3, x3, #16 cmp x3, #1024 bne .L4

fmla v2.4s, v0.4s, v1.4s一条指令完成了 4 个单精度浮点数的乘加操作，相比标量的 VFMA 又快了 4 倍。在支持 NEON 的处理器上，这属于“白捡”的性能红利，前提是你的循环结构足够规整，编译器才有机会自动向量化。

对于 M 系列处理器也类似。带 FPU 的 M7/M4 使用的是 M 系列特有的 FPU 指令集，GCC 在-O3下同样有机会生成向量化的vfma.f32，但前提是循环内没有任何复杂的控制流和函数调用。

5. 常见问题与排查技巧实录

5.1 为什么开了-ffp-contract=fast还是没生成 VFMA

这个问题在论坛里问的人特别多。按照我的排查经验，按顺序检查以下五步：

1. 确认目标架构参数是否正确。-mcpu和-mfpu必须匹配。如果是 Cortex-M4 但配了-mfpu=fpv5-d16，编译器会报错或warning。更隐蔽的是像 Cortex-M3 这种没有 FPU 的型号，你把它当 M4 用，编译选项配置错了，但编译器又因为算法库等原因没报错，最后生成的是__softfp__调用的代码，自然看不到任何浮点指令。

2. 确认优化等级不是-O0或-O1。-O0下不优化，-O1只做局部优化，大多不涉及浮点重关联。实测至少要-O2级别才会开始考虑 FMA 合并。

3. 确认代码中确实有浮点乘加表达式。如果你写的是float acc = a; acc = acc * b; acc = acc + c;，编译器可能每一步分别处理。尽量改成acc += a * b的形式。

4. 确认编译器没有把浮点操作降级为软浮点。反汇编后如果看到的是一堆 BL 指令调用了__aeabi_fmul、__aeabi_fadd之类的函数，说明编译时用了-mfloat-abi=soft，根本没有生成硬件 FPU 指令。要改成-mfloat-abi=hard或至少-mfloat-abi=softfp。

5. 确认 GCC 版本不要太老。GCC 4.x 时代对-ffp-contract的支持还不完善，建议使用 GCC 8 以上的版本。更强的建议是直接看 ARM 官方工具链，比如 arm-gnu-toolchain 的 12.x 版本。

5.2 为什么生成了 FMA 指令但性能反而变差

这个坑我在 Cortex-A 平台上遇到过。FMA 指令省了指令数，但改变了运算顺序，引入了中间结果的精度差异。在某些算法里，这会导致收敛速度变化或结果偏离期望值，进而影响整个系统的动态响应。

具体场景是卡尔曼滤波器的实现。默认的浮点运算顺序能保证协方差矩阵一定是对称正定的，但开启 FMA 后，因为舍入方式变了，矩阵可能在某些极端情况下变成非正定的，滤波器发散。这种问题表面上看是性能优化失败了，实际上是优化带来的副作用。

排查方法很简单：在开关快速浮点优化的两种版本下，分别把计算结果 dump 出来对比。如果差异大到影响功能，那就不要全局开启 fast-math，改为在热点函数局部用__attribute__((optimize("fp-contract=fast")))或者手动调用fmaf。

另一个性能反降的原因是操作数依赖链被破坏。有些编译器版本在某些循环结构下，虽然生成了 VFMA，但循环展开逻辑调整后，寄存器压力变大，频繁的内存加载（load）指令多了，反而掩盖了 FMA 带来的收益。这种情况下需要仔细比对整个循环体，而不只是看中间那一条 VFMA。

5.3 大小端与字节序对 VMLA/VFMA 的影响

这个坑相对隐蔽。在 ARM 上做 NEON 优化时，向量数据加载的顺序受大小端影响。如果你的系统是双端可配的（有些 ARM 处理器支持通过配置寄存器切换大小端），那么同样的代码，在小端模式下数据加载顺序是正常的，切到大端模式下，向量元素顺序可能就会反转，导致 FMA 的计算结果与你预期的不一致。

解决方向：如果你的代码中用到了vld1q_f32这种加载操作，建议配合vrev64q_f32做数据重排。还有就是尽量保持整个工程统一大小端设定，不要在代码里混用。这类问题通常不会在初期暴露，但到了联调阶段一旦出现，排查成本很高。

5.4 如何打通 RTOS 环境下的 FPU 上下文切换

跑 ThreadX、FreeRTOS 这种 RTOS 时，任务间的上下文切换需要保存和恢复 FPU 寄存器。如果你的代码里启用了 VFMA 指令，但又没在任务切换时保存 FPU 状态，那么任务 A 计算到一半，任务 B 切进来把 FPU 寄存器覆盖了，任务 A 再恢复执行时计算就全错了。

具体排查方法分两步：

1. 在 FreeRTOS 中，configUSE_TASK_FPU_SUPPORT必须设置为 1，并且在创建任务时为 FPU 上下文分配额外的内存。
2. 检查启动文件中是否有vPortSVCHandler和xPortPendSVHandler两个关键函数，它们内部必须有 FPU 寄存器的压栈弹栈代码，特别是要检查FPCCR寄存器的设置。

这个问题不属于“要不要用 VFMA”的范畴，而是用了 VFMA 之后必须配套处理的基础设施配置。很多朋友把性能优化做完了，一跑 RTOS 多任务就出幺蛾子，排查到最后发现是 FPU 上下文没保存。

5.5 混用 ARMCC 和 GCC 时的兼容性注意事项

很多项目做代码移植，从 Keil MDK 维护的老代码迁移到 GCC 工具链时，编译器版本和默认行为差异很大。ARMCC 的默认浮点行为在某些场景下更保守，即使不开任何 fast 选项也可能对部分表达式做融合；而 GCC 默认更严格地遵守标准。

但更实际的坑是，ARMCC 编译出来的目标文件在 GCC 环境里链接，或者反过来，可能会因为调用约定不完全一致而出现问题。尤其是浮点参数传递时，硬浮点（VFP 寄存器传参）和软浮点（栈传参）的 ABI 不一样。如果项目里有些库是别人用 ARMCC 编的，你自己用 GCC 编，-mfloat-abi=hard和-mfloat-abi=softfp一定要匹配，否则运行时的浮点参数会从寄存器里读到一堆垃圾数据。

解决方案：尽量统一工具链。如果实在无法统一，链接时确保两边都用-mfloat-abi=softfp，这种模式下浮点运算用 FPU 执行，但传参走软浮点 ABI，兼容性最好。

5.6 执行周期测量与仿真器差异

最后分享一个经验。很多人在 MDK、STM32CubeIDE 或者 GDB 仿真环境下测周期数，发现 VFMA 优化后的代码没有多大提升，很迷惑。实际上，仿真器（尤其是指令集模拟器）对流水线并行、cache 命中时延的模拟有误差。VFMA 带来的收益依赖硬件流水线的真实执行特性，在模拟器里常常体现不充分。

所以验证 VFMA 效果的正确姿势是：在真实硬件上用硬件定时器（DWT->CYCCNT 或者内核的 PMU 计数器）测量执行周期。以下是使用 DWT 测周期的一段代码示例：

// 初始化 CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; uint32_t start = DWT->CYCCNT; fir_baseline(data, coeff, history, output); uint32_t elapsed = DWT->CYCCNT - start;

elapsed就是实际执行的 CPU 周期数，这个数字比仿真器给出的参考值可靠得多。

6. 个人实操心得

6.1 从性能剖析到指令级调优的完整链路

做指令级优化时，建议的流程是：先做好性能剖析，用 perf 或者 DWT 计数器找到真正的热点函数，再针对热点函数做反汇编分析，确认瓶颈是指令条数多、还是依赖链导致流水线停摆。不要一上来就全局开启 fast-math 和 FMA 优化——那是最后一步，不是第一步。

另外，你在看编译器生成的汇编时，不要只看有没有 VFMA，还要看操作数是否来自寄存器还是内存。一条 VFMA 指令如果有一个操作数是从内存加载的，它的执行周期要加一个 load-use 延迟。这也是为什么前面说建议在循环外先加载数据到寄存器组，再批量执行乘加。

6.2 代码注释与可维护性

启用-ffast-math会让代码的可维护性降低。团队协作时，其他同事看到某个函数里运算顺序和自己预期的不同，第一反应往往是改代码，把乘加表达式拆成多行——结果又变回非优化状态了。

我的习惯是在源文件头部写明编译选项依赖：

/* * 本文件依赖 -O3 -ffp-contract=fast 编译选项 * 代码中大量使用乘加表达式，依赖编译器生成 FMA 指令提高性能 * 如需调整编译选项，必须重新评估浮点计算结果的差异 * 注意：本文件中的 FIR 滤波器是时延敏感代码，禁止在未确认的情况下修改循环结构 */

这对后续维护的人是一个提示，避免有人无意间破坏优化条件。

6.3 关于 NEON intrinsic 的补充说明

用 NEON intrinsic 写代码，比如vmlaq_f32，很多人以为写了就完事了，编译器一定会生成元素对应的指令。实际上取决于优化选项，编译器可能生成 VMLA，也可能生成 VFMA，还可能生成两条独立指令。

以 GCC 为例，即使你写了vmlaq_f32，在没有-ffp-contract=fast的情况下，它生成的就是标准的 VMLA 指令——这没问题，但它不会去优化成 VFMA。而如果开了-ffp-contract=fast，编译器在识别到内建函数的乘加语义后，才会将其转换为 VFMA。所以即使使用 NEON intrinsic，也别忘了配合开启动编译器选项。

从这个角度出发，我现在的代码写作习惯是：能用普通乘加表达式描述的，就不用 intrinsic；只有在做 128 位向量化且需要精确定位寄存器操作时，才用 intrinsic，同时保留-ffp-contract=fast编译选项。

6.4 性能浮动的警示

最后再提醒一点：VFMA 并不是在所有环境下都能稳定带来 20% 的收益。不同处理器的流水线不同，Cortex-A 系列的高端核心拥有乱序执行能力，指令数减少的效果可能被乱序窗口掩盖；Cortex-M 系列顺序执行但对时延敏感，指令数减少的效果更直接。而且缓存命中率、内存延迟、编译器版本都会影响最终性能。

所以做这类优化时，我坚持一个原则：以实际硬件上的性能计数器为准，不以反汇编判断为准。反汇编只能告诉你指令生成了没有，性能计数器才能告诉你这个生成到底有没有用、值不值得改代码结构去配合。

如果你正在做嵌入式算法性能优化，又恰好在跟乘加运算较劲，不妨按上面的流程走一遍：确认编译选项、检查代码结构、反汇编验证、实机测周期。只要这四步都对齐了，编译器生成 VFMA 就顺理成章了。我个人的体会是，代码运行速度的提升没有太多玄学，每一步都落到实处，结果自然就出来了。