做嵌入式性能优化做到第12期我一直在跟一条指令较劲VFMA融合乘加指令。它一条指令同时完成a*bc的计算而且只在最后一步做一次舍入。说它不起眼吧在 STM32H7、i.MX RT 这类带硬件 FPU 的 Cortex-M7/M4F 平台上跑 FIR 滤波、矩阵运算、PID 补偿这些“乘加大户”时指令数直接少一截缓存压力、取指压力都跟着降。说它麻烦吧很多朋友明明芯片支持、FPU也开了编译器却一板一眼地生成vmul.f32加vadd.f32两条指令性能原地踏步。这篇文章想把这件事彻底讲透VFMA 到底是什么编译器为什么“不主动”怎么通过编译选项、代码写法和内建函数让工具链老老实实吐出融合乘加指令以及在实际项目里会踩到哪些坑。适合正在做 ARM Cortex-M 平台底层优化、写 DSP 算法或者对编译器优化行为好奇的工程师。不需要你有汇编基础跟着步骤走一遍就能在自己的工程里复现。1. 追这条指令之前先弄明白 VFMA 在解决什么问题1.1 一条指令完成乘和加还只舍入一次VFMA 的完整名字是 Vector Floating-point Fused Multiply-Add在 ARM 的 VFP 指令集里对应VFMA.F32 Sd, Sn, Sm语义可以简单理解为Sd Sn * Sm Sd也就是把乘法和加法揉进一条指令中间不产生单独的乘法结果。这句话听起来简单背后最关键的一点是整个计算过程只有一次舍入。对比一下非融合写法。如果按照普通浮点运算来a*bc会先算乘法把结果舍入成单精度浮点再算加法把最终结果舍入一次。两次舍入意味着两次精度损失。而VFMA在硬件里用完整的中间精度完成乘加只在最后输出时舍入一次。数值上更接近实数的真实结果同时速度也更快。这里要顺带提一个容易混淆的指令VMLA.F32。VMLA 同样是一条指令完成乘加但它是 VFPv2/v3 时代的东西在不少 ARM 文档里被归为“非融合”操作仍然存在中间舍入。到了 VFPv4 引入 VFMA 之后真正的融合乘加才算在指令层面落地。你在反汇编里看到vfma.f32是好事看到老的vmla.f32也不用惊讶很多老版本编译器就爱这么干。1.2 哪些嵌入式芯片能用上 VFMA不是所有 MCU 都有资格谈论 VFMA。VFMA 依赖硬件浮点单元而且必须是支持 FMA 的 VFP 版本。我按实际工程里常见的 ARM Cortex-M 芯片整理了一下内核FPU 配置是否支持单精度 VFMA典型芯片Cortex-M0 / M0 / M3无 FPU不支持STM32F0 / F1 / F3部分Cortex-M4FVFPv4 单精度支持STM32F4、G4、L4、Kinetis K 系列Cortex-M7VFPv5 单/双精度支持STM32H7、F7、i.MX RT10xxCortex-M33FPv5 单精度支持STM32L5、U5、NXP LPC5500Cortex-M55MVE FP支持新一代 AIoT 芯片如果你用的是 Cortex-M0 或者不带 FPU 的 Cortex-M3那这篇文章里的 VFMA 跟你暂时无缘。芯片没有 FPU编译器只能调用软件浮点库比如__aeabi_fmul、__aeabi_fadd这种函数调用优化得再好也不可能合成 VFMA 指令。所以做优化之前先确认内核型号和 FPU 配置。1.3 为什么“一条指令”能撬动这么大的优化空间很多人觉得少一条指令而已能快到哪里去但放在循环里看账不是这么算的。假设你在做一个 64 阶 FIR 滤波器每个采样点要执行 64 次乘加。如果用vmul.f32vadd.f32组合每个乘加需要 2 条指令如果用vfma.f32每个乘加只要 1 条指令。仅指令数量就少了一半。Cortex-M 的取指带宽、解码带宽和发射带宽都是有限资源指令数少了循环体变小指令缓存命中率上升执行时间自然明显下降。还有一个容易被忽视的点编译器做循环优化、软件流水时指令数越少寄存器压力越小。融合乘加把“乘法的中间结果”和“累加器”合并成同一个寄存器编译器在安排寄存器分配时会更宽裕甚至能多做一重循环展开。这属于“一条指令引发的连锁收益”单纯算指令周期往往会低估它。2. 编译器为什么对 VFMA 这么“抠门”2.1 罪魁祸首是浮点精度语义这是最关键的一个原因也是大多数人卡住的地方。C 语言标准里float a, b, c;然后写a * b c编译器理解的是“先算乘法并舍入再算加法并舍入”。如果它直接优化成VFMA结果变成了“只有一次舍入”。大多数情况下结果更精确但严格从标准角度讲这属于改变了浮点运算的语义可能让个别测试用例的结果和对拍值不一样。所以编译器默认倾向保守除非你明确告诉它可以打破这个约束否则它就老老实实生成两条指令。GCC 和 armclang 里控制这个行为的选项是-ffp-contract有三个档位off禁止任何融合乘加优化。on只在语言标准允许的情况下融合受限于#pragma STDC FP_CONTRACT。fast只要目标硬件支持就大胆地把乘加模式融合成 FMA同时修改浮点语义也不再限制。实际工程里如果你的算法对最终结果的微小差异不敏感音频、控制、滤波基本都是这种情况直接用-ffp-contractfast是最省事的。如果项目里某个模块必须严格保证舍入行为那就在这个文件里用#pragma STDC FP_CONTRACT OFF单独关闭融合不要让全局选项把整个项目拖下水。2.2 FPU 没开对编译器不敢生成浮点指令第二个常见原因是浮点 ABI 没配对。ARM 平台有三种浮点选项选项参数如何传能否使用 FPU 指令说明-mfloat-abisoft通用寄存器不能纯软件浮点性能最差-mfloat-abisoftfp通用寄存器可以ABI 兼容好但函数调用开销大-mfloat-abihardFPU 寄存器可以性能最好推荐配合-mfpu指定 FPU 类型比如-mfpufpv4-sp-d16M4F或-mfpufpv5-d16M7。如果只指定-mfloat-abisoft编译器根本不会生成任何 VFP 指令而是调用软件浮点例程自然不可能有 VFMA。不少同学用 STM32CubeIDE 或者 Keil 创建工程时芯片型号选对了但浮点选项停留在默认值编译器就是给你生成一大串调用函数。打开 Map 文件看一眼如果大量出现__aeabi_fmul说明浮点 ABI 设置了改过来才能谈 VFMA。2.3 代码里的“隐形炸弹”堵死了优化路径即使编译选项都对了代码写法不合适编译器也没法下手。我见过几种情况中间结果被单独赋值写成float mul a * b; float ret mul c;编译器在严格模式下不一定敢把两行合并成 FMA因为mul这个中间结果在语义上是“已经舍入”的。指针别名问题如果编译器不确定a、b、c指向的内存是否重叠它可能为了安全性拒绝重排指令。写函数时对指针参数加restrict明确告诉编译器这些指针不会重叠。过度使用volatilevolatile变量会被编译器视为“每次都必须访问内存”这会让优化约束变得极强FMA 自然也无法生成。能用普通变量就别加volatile。把表达式拆到另一个函数里当一个乘加运算被拆到多个函数边界时编译器没有足够上下文做跨函数融合。加上-flto链接期优化可以缓解。写优化代码时最理想的形式就是让乘加紧密地出现在同一个表达式里然后交给编译器去处理。越直接的写法越容易被识别成 FMA 模式。3. 一步一步让编译器吐出 VFMA3.1 先把 FPU 使能别让硬件空转很多 Cortex-M 芯片的 FPU 默认不是打开的。如果你直接下载程序运行浮点指令可能触发 hard fault或者被当成分支指令解析表现千奇百怪。所以第一步确保 FPU 已使能。在 Cortex-M 上FPU 使能主要操作 CPACR 寄存器SCB-CPACR | ((3UL 10 * 2) | (3UL 11 * 2));这行代码把 CP10 和 CP11 协处理器访问权限设置为 full access之后浮点指令才被允许执行。在 STM32Cube 的 SystemInit 或者很多 CMSIS 启动文件里已经做了这件事但如果你用的是从别处拷贝的裸机工程最好在main开头加这段代码确认无误后再做其他操作。判断 FPU 是否生效最简单的办法是调式时查看 CPACR 的值或者干脆编译一个浮点加法程序看反汇编里是否出现vadd.f32。如果出现说明 FPU 已经活了。后续 VFMA 才有硬件基础。3.2 编译器选项怎么配GCC / armclang / AC5 对照不同工具链的选项名字不一样但核心就三件事指定内核、指定 FPU、开启浮点融合。以 STM32H743Cortex-M7支持双精度 FPU为例GCCarm-none-eabi-gccarm-none-eabi-gcc -mcpucortex-m7 -mfpufpv5-d16 -mfloat-abihard -O2 -ffp-contractfast -c fir.c -o fir.oarmclangAC6Keil MDK 6 / Arm Compiler 6armclang --targetarm-arm-none-eabi -mcpucortex-m7 -mfpufpv5-d16 -mfloat-abihard -O2 -ffp-contractfast -c fir.c -o fir.oarmccAC5老版本 Keil MDK 5armcc --cpuCortex-M7 --fpuFPv5SP-D16 --O3 --fpmodefast -c fir.c -o fir.oAC5 里对应 FP contraction 的选项不像 GCC 那么直接--fpmodefast就是告诉编译器可以进行更激进的浮点优化包括生成融合乘加。如果你的项目还在用 AC5记得确认这个选项。这里我特别强调一点要显式把-ffp-contractfast写进编译命令行。不要以为开-O2甚至-O3就够了-O3不等于开启 FP contraction很多默认配置下编译器依然保守。把-ffp-contractfast单独写出来一劳永逸。3.3 代码层面怎么“引导”编译器编译选项到位后代码写法的优先级也很重要。我一般按下面这个顺序处理第一尽量用直接的乘加表达式for (uint32_t i 0; i N; i) { y[i] a[i] * b[i] c[i]; }这个写法足够简洁编译器在-ffp-contractfast下很容易生成 VFMA。第二如果算法逻辑比较复杂担心编译器识别不出来可以直接调用 C 标准库的fmaf#include math.h float result fmaf(a, b, c);fmaf是标准库函数语义上就是“融合乘加只舍入一次”。编译器如果支持通常会把对fmaf的调用直接映射到硬件指令不需要额外优化推断。在嵌入式工具链里fmaf可能以内建函数的形式实现效率很高。第三想彻底控制直接用内建函数float result __builtin_fmaf(a, b, c);GCC 和 armclang 都支持__builtin_fmaf语义和fmaf一样但更明确地告诉编译器“我要生成硬件 FMA 指令”。在交叉编译环境下__builtin_fmaf比直接调用标准库函数更可靠因为有些精简的嵌入式 C 库根本没有实现fmaf链接时找不到符号。第四给指针参数加restrictvoid vec_fma(const float *restrict a, const float *restrict b, const float *restrict c, float *restrict y, uint32_t n) { for (uint32_t i 0; i n; i) { y[i] a[i] * b[i] c[i]; } }用restrict明确告诉编译器a、b、c、y指向的内存互不重叠编译器在优化时就有更多的自由去重排指令也更愿意生成 VFMA。尤其是在循环体内部编译器需要频繁加载数据并执行乘加如果它老是担心指针重叠会破坏结果就不敢用高性能指令序列。3.4 用反汇编验证是否真的生成了 VFMA这一步经常被忽略。选项配了一大堆结果汇编里还是vmul.f32vadd.f32一切白干。所以每次编译完我都习惯快速看一眼反汇编结果。GCC 工具链可以用 objdumparm-none-eabi-objdump -d fir.o如果你编译的是 ELF 文件也可以直接arm-none-eabi-objdump -d fir.elf然后搜vfmaarm-none-eabi-objdump -d fir.elf | grep vfma正常优化后你会看到类似这样的汇编片段vfma.f32 s4, s0, s1 vfma.f32 s5, s2, s3如果 grep 结果为空看一下是否有vmla.f32vmla.f32 s4, s0, s1有vmla说明编译器识别出了乘加模式但没有用新指令把 FPU 型号和-ffp-contract选项再核对一遍。如果连vmla都没有说明编译选项或代码写法还有问题回到前面几个步骤排查。3.5 一个完整的 FIR 示例从编译到反汇编我把整个流程串一遍照做就能在自己的工程里复现。假设有一段 FIR 滤波器核心代码#include stdint.h void fir_process(const float *restrict coeff, const float *restrict input, float *restrict output, uint32_t block_len, uint32_t tap_len) { for (uint32_t i 0; i block_len; i) { float acc 0.0f; for (uint32_t k 0; k tap_len; k) { acc coeff[k] * input[i k]; } output[i] acc; } }编译命令以 GCC 为例arm-none-eabi-gcc \ -mcpucortex-m7 \ -mfpufpv5-d16 \ -mfloat-abihard \ -O2 \ -ffp-contractfast \ -fno-common \ -c fir.c -o fir.o这里用-O2而不是-O0是因为没有优化等级编译器不会积极做指令选择。如果你只想实验-O1也够但-O2更接近实际项目。编译后反汇编arm-none-eabi-objdump -d fir.o你会看到内层循环里出现了类似vfma.f32的指令循环体被压得很紧凑。把-ffp-contractfast去掉重新编译再反汇编一次大概率就会变成两条指令的组合。对比两次汇编VFMA 带来的指令精简一眼就能看出来。4. 实测收益与几个容易踩的坑4.1 性能测试同样一段 FIR融合前后差多少我在一个 Cortex-M7 项目里做过对比处理器跑到 400 MHz用一段 64 阶 FIR 处理 1024 个采样点。开启-ffp-contractfast并成功生成 VFMA 后整体执行时间大概省了 12% 到 15%。这个数据在不同芯片、不同内存布局下会有波动因为瓶颈不一定在 CPU 算力上有时候内存带宽率先饱和。比较稳妥的建议是如果你的循环体里乘加运算占比高且数据都能放进寄存器或一级缓存VFMA 的收益会非常明显。如果数据需要频繁从外部 SDRAM 加载那瓶颈可能从“计算”变成“取数”VFMA 带来的指令数减少只能缓解一部分压力整体性能提升会缩水。测量时可以借助 DWT 循环计数器CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; uint32_t start DWT-CYCCNT; fir_process(coeff, input, output, 1024, 64); uint32_t cycles DWT-CYCCNT - start;压测时注意关掉中断或者记录中断消耗否则测出来的数据不准。4.2 坑1编译单元边界把 FMA 机会切断我之前遇到过一个案例把 FIR 处理函数放在 a.c调用处的循环在 b.c两个文件分别优化。b.c 里的调用点不知道 a.c 内部的结构编译器只能在函数调用层面做优化无法跨文件把乘加模式融合到一起。解决办法是开链接期优化-flto让编译器看到完整的调用链。GCC 和 armclang 都支持。不过开了-flto后编译时间会变长链接时的内存占用也会增加。对于大型工程可以先只在关键的算法模块上开 LTO比如用 CMake 设置INTERPROCEDURAL_OPTIMIZATION属性而不是全局无脑开启。另外一个思路是直接把内循环写到调用处或者在头文件里用static inline函数。这样编译器在调用点就能看到完整代码即使不开启 LTO也有一定概率生成 VFMA。4.3 坑2中断和 RTOS 环境下 FPU 上下文VFMA 本身不涉及额外状态但使用 FPU 的代码在上下文切换时要注意。Cortex-M 的 FPU 寄存器是 S0-S31共 32 个单精度寄存器或者 16 个双精度寄存器。中断触发时如果中断服务函数里也用到浮点运算硬件会自动保存一部分 FPU 状态但如果用了 RTOS任务切换时就要确保保存了完整的 FPU 上下文。FreeRTOS 里有个配置项configUSE_TASK_FPU_SUPPORT或者类似的选项需要在移植层确认。如果你的一个任务使用了 VFMA另一个任务不使用浮点但两个任务切换时没有正确保存 FPU 寄存器就会导致计算结果被篡改。这种错误特别隐蔽通常表现为程序跑一会儿后数值突然异常。给一个实用的建议项目里如果大量使用浮点运算尽量把 FPU 上下文切换开关统一打开不要为了省那一点上下文保存时间而关闭得不偿失。中断里也一样如果确认中断服务函数里不用浮点可以把FPCCR的自动保存配置成 lazy stacking能省不少中断进入时间如果不确认就保持默认的完整保存安全第一。4.4 坑3换了编译器或优化等级后指令消失还有一个很常见的情况代码在同事的 GCC 环境下生成了 VFMA到了你的 Keil AC5 环境里就没了或者同一个编译器从-O2换成-O3反而消失了。这种“飘忽不定”往往让人抓狂。原因有几个不同编译器处理 FP contraction 的默认策略不同GCC 的默认策略和 armclang 不一定一致。优化等级改变后编译器可能选择不同的循环结构比如展开、向量化导致乘加模式不再以原来的形式出现。-O3可能触发自动向量化在 Cortex-M55 等支持 MVE 的芯片上会生成.f16或.f32向量指令VFMA 被“更高层次的优化”替代。这不算坏事但如果你专门想看标量 VFMA可以用-fno-tree-vectorize关掉向量化。我的习惯是在工程配置里显式写清楚编译选项包括-ffp-contractfast、内核型号、FPU 型号、浮点 ABI。不要依赖编译器默认值否则升级工具链版本后同样的代码可能编译出完全不同的汇编。5. 遇到问题时怎么快速排查FAQ我整理了一个快速排查表按“症状 - 原因 - 解决”的思路来做优化卡壳时直接对照症状可能原因解决方法反汇编里没有vfma也没有vmla编译器不知道目标支持 FMA或 FPU 选项没开核对-mcpu、-mfpu、-mfloat-abihard有vmla.f32没有vfma.f32FPU 型号不够新或编译器版本偏老换支持 VFPv4 以上的内核/编译器选项考虑__builtin_fmaf所有浮点运算都变成函数调用浮点 ABI 设置成了soft改成-mfloat-abihard同一份代码AC5 和 AC6 结果差异大AC5 的 FP contraction 默认策略不同AC5 加--fpmodefastAC6 加-ffp-contractfast中断或任务切换后数据偶尔错误RTOS 或中断没保存 FPU 上下文开启 FPU 上下文切换检查 FPCCR 配置加了restrict后仍然没有 VFMA编译优化等级太低或 LTO 未开启至少用-O2必要时-flto局部变量被volatile修饰volatile 阻止编译器重新排序和融合去掉非必要的 volatile使用fmaf时链接报错嵌入式 C 库没实现fmaf改用__builtin_fmaf或内联汇编这个表其实就是我平时优化排障的一个缩影。先检查编译选项再检查代码写法最后再去怀疑硬件和运行环境。顺序反了容易浪费时间。6. 关于“把乘加写开”和使用内联汇编的最后一点建议聊到这里VFMA 的核心知识点基本都过了一遍。最后分享一个我个人的习惯除非万不得已不要一上来就用内联汇编去写vfma.f32。内联汇编虽然能百分之百保证生成目标指令但会让编译器失去优化空间比如循环展开、寄存器重命名、指令调度都可能被打断。遇到代码简洁、逻辑固定的聚核可以适度用__builtin_fmaf达到目的编译器能在保留优化能力的同时生成想要的指令。只有当你确认编译器在各种情况下都无法生成 VFMA并且这段代码是性能决定性代码时才值得把注意力转向内联汇编。我实际项目中会先在实验环境里测试编译器行为写一个最小例子编译、反汇编、确认 VFMA 出现再把这个最小例子的写法复制到大工程中。这个方法治好了我不少“玄学性能问题”。做嵌入式优化很多时候不是芯片不够快而是工具链没有被正确引导。把 VFMA 这一条指令拿捏住你的浮点运算循环就能明显变得轻盈。