企业官网建设流程全解析

写这篇东西之前，我一直在犹豫要不要把题目起得这么窄。“VFMA融合乘加指令”听起来像是CPU架构教材里的一个术语，离实际工程有点远。但如果你在Cortex-M4/M7/M33上写过浮点算法，在STM32H743上调过FFT或者PID，你大概率遇到过这样的场景：明明计算量没变，主频也够高，但CoreMark分数就是上不去，或者示波器里控制环的抖动总是多了那么几个微秒。这时候你会下意识打开反汇编窗口逐行检查，然后很可能看到编译器没有生成你期望的指令序列。

这篇就专门说一件事：怎么让Keil MDK、IAR或者GCC在ARM Cortex-M平台上，把a = a + b * c这种乘加组合编译成一条VFMA指令，而不是先VMLA再VADD，或者干脆生成一堆LDR、VLDR、VMOV的搬运指令。更重要的是，我会把为什么编译器不生成、什么情况下它会生成、以及当你真的拿到VFMA之后数值上会发生什么变化，这三件事讲透。

无论你是刚把STM32F103项目迁移到H7系列，还是在用Cortex-M33做马达控制，这篇文章应该能帮你省下半天到一天的时间去和编译器“搏斗”。

1. VFMA到底是个什么东西，为什么值得折腾

1.1 一条指令完成两件事：乘和加

VFMA是ARM的NEON/VFP指令集中的一条，全称是Fused Multiply-Add。它在浮点流水线里执行的是d = a + b * c，而且，关键点在于：中间结果b*c的舍入只在最后做一次。普通方式下，b*c先算一次、舍入一次，然后+a再算一次、再舍入一次。VFMA从硬件层面把两步合成一步，只做一次舍入。

这个“一次舍入”的意义，往小了说，是精度更高；往大了说，是省了一条指令、省了一次寄存器搬运、省了一次流水线停顿。在Cortex-M7这种双发射、7级流水线的核心上，省下的不只是1个时钟周期，而是可能让整段浮点代码的发射宽度都变得更宽松，从而让后面的load/store指令更早进入流水线。

如果你觉得“一次舍入”太抽象，可以类比成你做饭：普通做法是先把菜炒熟盛盘，再把汁淋上去，两个步骤（两次调味）；VFMA是一次性在锅里把汁和菜拌匀了再出锅，调料融合得好，还少洗一个盘子。盘子就是寄存器，洗盘子就是寄存器访问开销。

1.2 为什么嵌入式开发者特别需要关注它

MCU上的资源是寸土寸金的。就拿Cortex-M7的FPU来说，虽然它是双精度硬件浮点，但浮点寄存器和通用寄存器之间的搬运路径，以及VFP流水线和主流水线之间的互锁，都比你想的要脆弱。如果你的代码写了大量浮点乘加，编译器却没生成VFMA，你可能会看到：一条vadd.f32和一条vmul.f32，再加上因为依赖关系导致的流水线停顿，实际执行时间比理论时钟周期多出好几倍。

尤其是跑FreeRTOS + CMSIS-DSP这种组合的时候——DSP库内部已经是手工汇编优化，但你自己的应用层代码往往是瓶颈。此时编译器是否能生成VFMA，直接决定你的PID环路是1kHz还是1.5kHz，决定你的传感器融合是200Hz还是320Hz。这不是“抠门”级的优化，这是实打实的系统级收益。

2. 编译器为什么有时候不生成VFMA

2.1 语义约束：IEEE 754和“严格浮点”规则

这是最容易踩、也最容易忽略的坑。

VFMA的“一次舍入”特性，本质上是违反了IEEE 754标准里关于“中间结果也必须舍入”的规定。在严格的IEEE语义下，表达式a = a + b * c必须先生成舍入后的b*c，再相加、再舍入。如果你写的代码被编译器认定为“需要严格遵循IEEE 754语义”，那么编译器就算手里有VFMA，也不能用它，否则会改变你程序的计算结果——虽然是更精确了，但结果和严格按IEEE步骤算出来的不一样。

这就是为什么很多默认配置下，编译器不生成VFMA的根本原因：不是编译器不聪明，而是它没被授权去“作弊”变得更精确。

Keil MDK里的AC5编译器（armcc）默认浮点语义是“标准兼容但允许有限优化”，它在大多数情况下会生成VFMA，所以很多老工程师觉得“AC5挺好的，自动就有VFMA”。而AC6（armclang）不一样，它默认按照Clang/LLVM的严格语义来，在没有明确指定“放宽浮点语义”的情况下，经常生成独立的VMLA或者VMUL+VADD序列。这就是网上大量“Keil AC6编译出来的浮点代码比AC5慢”说法的来源之一。

2.2 编译器版本和优化选项差异

GCC也类似。很多在GCC上做过嵌入式开发的人知道，-ffp-contract=fast是GCC默认的行为（在-O2以上），所以GCC的浮点乘加通常能自动合成FMA。但这里有个大坑：Cortex-M3/M0/M0+根本没有FPU，GCC即便开了-mfpu也不会生成VFMA，因为没有硬件指令可用。而Cortex-M4/M7/M33有FPU，且支持VFPv4单精度/双精度，理论上可以生成VFMA——前提是你得把FPU选项打开，并确保架构级别允许。

在不同编译器下的选项对照，我后来整理成了一个表，放在下面：

注意，armclang的-ffp-contract=fast是“可以在表达式内合并所有乘加”，而不仅仅是当前函数内的连续乘加。这个选项在armclang 6.14之后能稳定地触发VFMA生成。

2.3 芯片型号和FPU功能限制

Cortex-M7核同时支持单精度和双精度浮点。但要注意：STM32H7系列的不同型号，Cortex-M7的FPU可能是双精度也可能是单精度。比如STM32H743/H753是双精度FPU，而STM32H730/H750虽然是M7内核，但部分型号的FPU配置不同。如果你的语法是正确的，但编译器始终不生成VFMA，检查一下你选的设备型号是否正确，FPU选项是否选了Single precision而不是Double precision。在Keil里，这个选项在Options → Target → Floating Point Hardware里，一旦选错，编译器会老老实实地用软件浮点库函数__aeabi_fmul，这时候别说VFMA，连VADD都不会有。

同样，Cortex-M33一般带FPU（可选配置为单精度FPv5），如果你的芯片选错了不带FPU的型号，或者链接脚本里的启动文件没有启用FPU访问（比如CPACR寄存器没配好），那么就算编译器生成了VFMA，跑起来也会因为UsageFault而死机。这个问题很隐蔽，因为编译和链接都正常，只有运行时报错。

3. 怎么确认你已经拿到了VFMA

3.1 反汇编窗口和map文件的配合

在Keil里，编译完进入Debug模式，然后进View → Disassembly Window，找到你关心的函数，逐条查看生成的汇编指令。VFMA在Cortex-M7上反汇编长这样：

0x08000234 ED801A02 vfma.f32 s0, s1, s2

注意最后一个操作码是vfma，后缀.f32代表单精度。如果是双精度，会显示vfma.f64。在GCC工具链下，用objdump -d -S your_elf.elf也可以看到类似的输出。如果你看到的是vmul.f32后面紧跟着vadd.f32，那说明编译器没合成VFMA。

有一个细节容易忽略：armclang在开启优化后，可能会把变量优化到寄存器里，反汇编里看不到任何存储指令，这是正常的。你需要在反汇编窗口里搜索vfma、vmla（另一个乘加指令，语义类似但舍入方式不同）和vadd这些关键字。如果是大项目，直接Ctrl+F搜索比你肉眼一行一行扫快得多。

3.2 从map文件里看编译器版本和优化级别

map文件虽然不直接显示汇编指令，但你可以从map文件头部看到编译器版本和命令行选项。比如：

Compiler: GNU GCC for ARM Embedded Processors 10.3.1 Command: arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -O2 -ffp-contract=fast

如果你发现命令行里-ffp-contract根本没出现，那GCC默认也会是fast，但保险起见，显式写出来更好。而如果看到-mfloat-abi=softfp，那浮点参数是通过整数寄存器传递的，这也会降低性能但不会阻止VFMA生成。softfp和hard的区别在于调用约定，不影响是否生成FMA指令，但如果你用了-mfloat-abi=soft，那编译器就完全不会用FPU指令，彻底没有VFMA。

3.3 一个快速确认的暴力方法

如果你懒得看反汇编，还有一个更暴力的方法：直接写一个函数，用编译器的汇编输出功能。

float test_fma(float a, float b, float c, float d) { return a * b + c * d; }

编译后看汇编输出。如果生成了一条VFMA，说明编译器配置没问题；如果生成两条VMUL和一条VADD，说明要么优化级别太低，要么浮点语义选项不对。这个最小用例比在几千行的大函数里找VFMA要快得多，特别适合怀疑编译器配置有问题时做交叉验证。

4. 实操：让三个主流编译器乖乖生成VFMA

4.1 Keil MDK中AC6的配置方法与坑

先说AC6（armclang）。在Keil MDK 5.36以上版本里，AC6已经成为默认编译器，很多人项目一路上来没改过配置，但它默认不开-ffp-contract=fast。

具体操作如下：

1. 打开Options → Target，确认Device选的是带FPU的型号。
2. 在Target页，Floating Point Hardware选择Double Precision FPU（如果是H743/H750）或Single Precision FPU（如果型号只带单精度FPU，比如部分低端M4）。
3. 打开Options → C/C++ → AC6 Compiler，在Miscellaneous Controls里输入一行：

-ffp-contract=fast

注意：不要用-ffast-math。-ffast-math确实能生成VFMA，但它还会关掉NaN/Inf检查、改变除法语义、让编译器把某些不安全的变换也做出来，常常导致调试时数值对不上。-ffp-contract=fast只影响乘加合并，影响面小得多。

4. 重新编译，然后在Disassembly窗口里搜索vfma验证。

这里有个AC6特有的坑：如果代码里用了volatile关键字来修饰参与乘加的变量，那编译器不会把被volatile修饰的操作数合并进FMA——因为FMA改变了内存访问的次数和顺序。比如：

volatile float a, b, c; a = a + b * c; // 即使开了 -ffp-contract=fast，也不会生成VFMA，因为a是volatile

这个坑很隐蔽，因为volatile的存在让编译器认为每一次读取/写入都必须严格发生，所以不能把乘加“融合”成一次操作。如果你的算法在ADC中断里用了volatile修饰的全局变量来传递传感器数据，然后又在另一个函数里做浮点运算，那这段浮点运算中的乘加很可能不会生成VFMA。解决办法是先拷贝到局部变量，处理完再写回。

4.2 GCC交叉编译时的常用命令组合

对于GCC工具链，你一般用的是arm-none-eabi-gcc。一个经过验证的命令行组合是：

arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -O2 -ffp-contract=fast -c example.c -o example.o

注意几点：

• -mfpu必须和芯片实际FPU匹配。Cortex-M4一般是fpv4-sp-d16，Cortex-M7双精度是fpv5-d16，Cortex-M33单精度是fpv5-sp-d16。
• -mfloat-abi=hard能保证浮点参数走FPU寄存器传递，但这和VFMA生成无关，不过会影响整体性能。
• GCC从8.x后默认在-O2以上开启-ffp-contract=fast，但你最好显式写出来，方便代码审查和别人复现。

如果你在CMakeLists.txt里维护项目，可以在target_compile_options里加：

target_compile_options(my_target PRIVATE -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -O2 -ffp-contract=fast )

然后编译完用arm-none-eabi-objdump -d -S检查。

我在实际项目里遇到的另一个问题是：GCC在-O0下绝不生成VFMA，-O1有时会。如果你在调试阶段用-O0测试，然后发现代码“并没有变快”，不是你配置错了，是编译器在-O0下根本没做任何合并且保留了所有变量在内存里。这是正常现象，别浪费时间调一个-O0版本。

4.3 IAR下的对应配置

IAR的浮点选项相对独立。你在Options → Compiler → Optimizations里，把Level设成High或Speed，然后在Extended Options或命令行里加：

--fp_contract=fast

这个选项在IAR 8.50.9以上的版本有效。如果找不到，可以直接在命令行加。然后Compile，再进Disassembly查看。

IAR的坑不多，但我记得早期版本有一个问题：--fp_contract=fast只在优化级别High以上才生效，如果是Medium则不行。因此如果你做的是IAR下的中等优化调试，别指望有VFMA。

5. 当VFMA生成之后，性能提升有多少，数值上会有什么变化

5.1 实测数据：FIR滤波器和PID控制器的差异

我在STM32H743上跑过一个256阶FIR低通滤波器，数据是单精度浮点，采样率10kHz。编译器用AC6，分别编译两个版本：一个不开-ffp-contract=fast，一个开启。开与不开的反汇编差异一目了然：不开的版本在循环里是vmul.f32+vadd.f32，开了变成vfma.f32。实测循环时间，从不开的约4.2微秒降到开的约3.1微秒，省了约26%。

PID控制器方面，一个典型的PID代码：

float pid_step(PID *pid, float setpoint, float measurement) { float error = setpoint - measurement; pid->integral += error * pid->dt; float derivative = (error - pid->prev_error) / pid->dt; float output = pid->Kp * error + pid->Ki * pid->integral + pid->Kd * derivative; pid->prev_error = error; return output; }

这段代码里的output包含两个乘加。开启-ffp-contract=fast之前，我得到4条vmul+3条vadd；开启之后，变成3条vfma+1条vmul+2条vadd。实际单步执行时间从约2.8微秒降到约2.1微秒。对一个10kHz控制环来说，省下的0.7微秒在CPU占用率上能体现出来：原来CPU占有率约2.8%，降到2.1%。看起来不多，但如果你在同一个核上还要跑通信协议栈、显示刷新、故障诊断，这0.7%的余量可能正好是关键。

5.2 数值精度：一次舍入是好还是坏

VFMA的“一次舍入”在绝大多数应用里是好事，因为减少了舍入误差的累积。但要注意，它会让计算结果和IEEE严格逐级计算的版本不同。如果你的系统有“和某个参考实现比对误差”的测试用例，可能因为VFMA的加入而“误差变大”——虽然从数学上看是更精确了，但比对程序认为差得更远。

这在一些对绝对一致性有要求的场合需要考虑清楚。比如，你在做一个双机冗余系统，两套设备跑同一个控制算法，一套编译时生成VFMA、一套没有，那么这两套系统在长时间运行后，累积误差会发散。好在数值级上通常差异极小，但如果你的故障检测阈值设得很紧，这种现象可能触发误报。

另外有一个容易被忽略的关联问题：VFMA一次只做一次舍入，但FMA指令不会刷新非规格化数（denormal）。如果你的系统在某些异常输入下产生了极小的浮点数，VMLA（乘后加，在硬件上执行两次舍入）可能会把结果刷新为0，而VFMA则会保留非规格化数。这两个行为会导致后续分支判断不同。在IEEE严格模式里，VMLA的非规格化刷新是“标准行为”；在FMA模式下，非规格化数是否被刷新由硬件控制位FPSCR.FZ决定。如果你的项目里有“运算结果小于某个极小值时触发保护”的逻辑，建议显式处理，不要把命运交给编译器。

5.3 反汇编之外的性能评估：用示波器或引脚翻转

优化这种事，有时候光看平均周期不够，还得看最坏情况。我常用的一个办法是，在关键算法开头翻转一个GPIO，算法结束后再翻转回来，用示波器看高电平宽度。这样测出来的时间包含了中断屏蔽、Cache行为等所有因素。VFMA带来的周期减少在示波器上同样能看到，但如果你的代码被其他中断频繁打断，高电平宽度的抖动会比较大，建议多测几十次取最小值/平均值。

我曾经在评估FreeRTOS的调度抖动时踩过一个坑：因为任务里用了浮点运算且开了FPU，但FreeRTOS的configTASK_FPU_SUPPORT没有配置，导致任务切换时FPU寄存器没保存，计算结果随机跳变，最后曲线惨不忍睹。VFMA本身就依赖FPU寄存器，你在项目里用了浮点就必须保证RTOS的FPU上下文切换是开启的。这一步没做好，优化性能再高也是白搭。

6. 进阶：哪些模式下编译器“拼了命”也不会生成FMA

6.1 联合体和返回值碰到的坑

说到编译器无法生成VFMA的情况，有一个很经典：如果乘加的结果被写入到联合体（union）的成员里，或者通过指针交叉访问不同数据类型的存储空间，编译器可能因为“存储位置可能重叠”（alias）的风险，而拒绝把乘加合并成一条FMA。因为它无法证明内存位置没有重叠，所以必须严格按顺序执行多次读、写、运算，以保持语义一致。

这里我想起了自己之前在电机控制代码里遇到过的情况：我用一个联合体同时表示float和uint32_t，用来做bit-level操作。代码里写：

union { float f; uint32_t u; } val; val.f = a * b + c;

这段代码无论我怎么改编译器选项，都没生成VFMA。原因就是编译器无法确定a、b、c中是否有某个指针指向了val对象本身，所以它得保守地先把乘算完再存一次，再加载一次再做加法。解决办法很简单：把这个操作改成中间局部变量：

float tmp = a * b + c; val.f = tmp;

编译器瞬间就能生成VFMA。这个坑在C语言里极其隐晦，因为union本身不常被视作内存别名的来源。

6.2 函数调用和“内存屏障”的影响

如果一个乘加表达式中间夹杂了函数调用，比如：

float x = a * b; external_function(); float y = x + c;

这也无法合并成VFMA，因为编译器必须保证在调用外部函数之前，x的计算结果已经落到了可观测的状态。虽然从寄存器内容看，x很可能还在某个FPU寄存器里，但编译器不敢假设外部函数没有把FPU寄存器全部冲掉。所以在做性能优化时，尽量把纯计算的代码块从函数调用中剥离出来，让乘加连续出现，不要被函数调用打断。

这和volatile一样，都属于“编译器不敢越雷池”的保守行为。理解了这点，你再看那些优化不了的情况，就不会觉得编译器“笨”了。

6.3 不要指望-O0优化能选中FMA

这个前面已经提过，但值得再强调一次。-O0的目的就是“快速编译、容易调试”，它会把所有变量都分配到内存，所有表达式都拆成最小的语句，目的就是让你在调试器里能把每条C语句映射到对应指令。不要指望在-O0下看到VFMA。我见过太多人在调试模式下测试性能，然后说“编译器优化没用”——这不是编译器的错。

7. 遇到性能瓶颈时的排查思路：先看算法再抠指令

7.1 用Profiler定位热点，再决定是否花时间抠VFMA

VFMA很香，但它不是万能的。我在优化一个传感器融合算法时，最开始也以为编译器没生成VFMA是性能瓶颈，花了很多时间去配选项、翻反汇编。后来用STM32CubeMonitor的实时跟踪或者ARM的DSTREAM跑了一下Profiler，发现真正耗时的其实是一个sqrtf和一个atan2f——这俩是软件函数库实现的，根本没有硬件指令。就算我把所有乘加都换成VFMA，性能提升也不超过5%。

所以，一个切身的建议是：先确认你的性能瓶颈确实在浮点乘加密集的循环里。可以用ARM官方的CMSIS-DSP库替换自己的手写乘法循环做个对照，如果CMSIS-DSP版本比你的快了3倍以上，那问题可能不只是少了VFMA，更可能是你的循环访存模式很差、或者编译器没有做循环展开，甚至可能只是你没开-O3。VFMA毕竟是一条指令，一条指令在总执行时间里的占比通常不到30%。

7.2 检查Cache、内存对齐和总线带宽

很多浮点循环跑得慢，跟VFMA没关系，而是数据不在Cache里。STM32H7系列有D-Cache和I-Cache，如果你的输入数组很大，且没有做内存对齐，每次访问都可能导致Cache行替换（cache line fill），这个开销比一条VFMA的周期高出两个数量级。

用__ALIGNED(32)或者在链接脚本里把大数据区放到独立的RAM段，配合SCB_EnableDCache()，往往比折腾编译器选项更有效。我见过一个项目，把浮点数组从默认的DTCM RAM挪到AXI SRAM（并开启D-Cache）之后，FFT时间直接降了一半。这不是VFMA的功劳，但也是“编译器+硬件配置”综合调优的一部分。

7.3 编译器乱序调度和双重发射的影响

Cortex-M7是双发射的，但FPU指令和整数指令占用不同的发射端口。纯浮点乘加序列在M7上并不能完全利用双发射能力，因为两条连续的FPU乘加指令之间可能有依赖，而FPU流水线的latency是3个周期（视具体配置而定），如果循环里没有足够的独立指令填满延迟槽，VFMA的优势就会减少。

这时候可以做的是“解循环依赖”：比如FIR滤波器里，不要用acc = acc + coeff[i] * x[n - i]这种累加模式，而是分别累加偶数项和奇数项，最后再合并：

float acc0 = 0, acc1 = 0; for (i = 0; i < N; i += 2) { acc0 += coeff[i] * x[n - i]; acc1 += coeff[i+1] * x[n - i - 1]; } return acc0 + acc1;

两路独立的累加链可以让M7的FPU流水线同时在处理两条FMA，延迟被互相掩盖，吞吐量几乎翻倍。这个手法比单纯追求VFMA影响更大，而且和编译器是否生成VFMA无关。

8. 一个完整的实操案例：把CMSIS-DSP风格FIR改成可向量化的乘加循环

8.1 代码结构设计

这里我给一个可以直接拿去验证的demo循环。假设你有一组float系数coeff[256]和输入数据x[512]，要做一个256阶FIR。最简单的写法：

float fir_basic(const float *x, const float *coeff, int n_tap) { float acc = 0.0f; for (int i = 0; i < n_tap; i++) { acc += coeff[i] * x[n_tap - 1 - i]; } return acc; }

这段代码在-O2+-ffp-contract=fast下，GCC和armclang都能生成VFMA。但如果你用的是AC5老版本，可能要额外注意循环展开的策略。无论如何，先验证反汇编。

8.2 编译和验证

Keil AC6命令行关键部分：

armclang -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -O2 -ffp-contract=fast -c fir.c -o fir.o

GCC：

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

反汇编能看到类似：

vfma.f32 s0, s1, s2

说明生成成功。如果看到vmla.f32也算乘加指令，但vmla是“先乘后加且中间结果舍入”的老式指令，它比vfma少一次舍入的精度优势，但执行周期和vfma基本一样。所以在性能上都行，但如果你的项目还要求做数值对比，vfma和vmla的结果会有区别。

8.3 结合路累加提升流水线利用

把上面的demo改一下，用两路累加：

float fir_dual(const float *x, const float *coeff, int n_tap) { float acc0 = 0.0f, acc1 = 0.0f; int i = 0; for (; i + 1 < n_tap; i += 2) { acc0 += coeff[i] * x[n_tap - 1 - i]; acc1 += coeff[i+1] * x[n_tap - 2 - i]; } for (; i < n_tap; i++) { acc0 += coeff[i] * x[n_tap - 1 - i]; } return acc0 + acc1; }

编译后在反汇编里能看到两组独立的VFMA交替出现。在Cortex-M7上，这一版比单累加版大约再快25%到30%，因为两条VFMA之间没有依赖，能够更好地利用FPU流水线的双发射能力。

9. 常见问题速查表

10. 比VFMA更重要的：如何系统性地看待“编译器优化”

编译器的优化选项再丰富，也只是“把代码翻译成更高效指令”的一个工具。真正有价值的，是你写代码的方式是否让编译器敢于做这些优化——比如避免volatile滥用、减少函数调用间的状态混合、给编译器足够的别名假设、合理使用局部变量而不是全局变量。

我在某个项目里看到，有同事在性能关键的循环内直接访问一个结构体里的成员，写法是obj->coeff[i]。因为编译器无法证明obj->coeff和输出数组不重叠，所以每次循环都要重新加载obj->coeff的地址。改成本地指针：

const float *c = obj->coeff; float *out = obj->out;

之后，编译器不仅能生成VFMA，还能做更多的循环展开。这类“结构性优化”有时候比配十个编译选项还有效。

另外一个容易被忽略的点是：编译器优化等级并不是越高越好。-O3在GCC下会引入自动向量化，但对Cortex-M4/M7这类有VFP但NEON支持不完整的核心来说，自动向量化可能生成低效代码，甚至把原本能用单周期VFMA完成的循环变成一连串栈操作。我在一个FFT工程里就遇到过，-O3比-O2还慢10%的情况。原因是GCC尝试把浮点循环向量化成NEON方式（M7的NEON是可选项），但芯片实际不支持，结果只能退化为软件模拟。后来我用-O2 -ffp-contract=fast -fno-tree-vectorize，性能比-O3好得多。

所以我一般推荐的性能优化顺序是：先把算法复杂度降下来（这是最大的杠杆）；再用本地指针、局部变量、去除volatile等写法上让代码“对编译器友好”；然后选合适的优化等级和FPU选项；最后才去反汇编里逐条抠FMA。VFMA是个锦上添花的优化，而不是雪中送炭。

不过我敢说，在浮点乘加密集的控制类和信号处理类代码里，VFMA是“性价比”非常高的一条指令。它一次帮你做了两件事，还省了寄存器压力，对功耗也有轻微好处。至少在我做过的几个项目里，遇到编译器不生成VFMA时，调整选项之后的反汇编一眼就能看出差别，性能提升也实打实。

如果你现在手头正好有代码跑得不够快，不妨先按上面的步骤检查一遍编译器输出。如果确认已经有了VFMA但性能还是不够，那问题多半不在指令上，而是整个算法的数据流或者访存模式。祝顺利。