三、RA8D1 CoreMark测试GCC vs AC6和分散加载浅析

一、概述RA8D1 搭载 Cortex-M85 内核主频 480MHz使用 GCC(13.3.1) 和 AC6(Clang 20.0.0git) 两种工具链编译 CoreMark测试不同优化等级、内存布局CacheSRAM、TCM对跑分的影响二、测试环境项目参数芯片RA8D1内核Cortex-M85主频480MHzGCC 版本13.3.1 20240614AC6 版本Clang 20.0.0gitCoreMark Size666 (2K)Iterations80000三、GCC 跑分结果3.1 测试配置与结果编号配置Iterations/SecCoreMark/MHz1-Ofast fsp.ld默认链接2286.374.762-Ofast fsp.ld stack 放 DTCM2343.574.883-Ofast fsp_tcm.ldTCM链接2341.304.884-Ofast fsp_tcm.ld stack 放 DTCM2341.374.883.2 GCC 结果分析默认链接脚本4.76 CoreMark/MHz基线成绩Stack 放入 DTCM提升到 4.88 CoreMark/MHz提升约 2.5%TCM 链接脚本与 stack 放 DTCM 效果接近约 4.88 CoreMark/MHzGCC 下 TCM 带来的收益有限说明代码主要已在 Cache 中命中四、AC6 跑分结果4.1 测试配置与结果编号配置Iterations/SecCoreMark/MHz1-Ofast stack 放 DTCM2688.355.602-Ofast stack 放 DTCM fsp_tcm.scat2683.305.593-Omax fsp_tcm.scat2780.775.794-Omax fsp.scat默认链接2780.775.795-Omax stack 放 DTCM2974.976.204.2 AC6 结果分析-Ofast 基线5.60 CoreMark/MHz已明显高于 GCC 的 4.88-Omax开启 LTO5.79 CoreMark/MHz比 -Ofast 提升约 3.4%-Omax stack 放 DTCM6.20 CoreMark/MHz最高成绩AC6 整体比 GCC 高约 27%5.60 vs 4.76 基线对比五、GCC vs AC6 对比汇总对比维度GCC (-Ofast)AC6 (-Ofast)AC6 (-Omax)基线默认链接4.765.605.79Stack 放 DTCM4.885.606.20TCM 链接脚本4.885.595.79最高成绩4.885.606.20六、AC6 优化等级与 LTO 详解6.1 -Ofast vs -Omax优化等级LTO说明-Ofast不启用激进优化但不做跨模块链接时优化。允许浮点重结合等可能违反标准合规的变换-Omax默认启用最大优化等价于 -O3 -flto。启用所有优化包括跨模块内联、死代码消除和链接时优化6.2 什么是 LTOLink Time OptimizationLTO 是一种跨模块的过程间优化在链接阶段而非编译阶段执行编译阶段armclang 使用 -flto 时生成bitcode字节码文件而非标准 ELF 对象文件。Bitcode 包含源代码的中间表示IR和模块依赖信息链接阶段armlink 处理 bitcode 文件提取模块依赖信息传递给 llvm-lto 工具优化阶段链接时优化器分析所有模块移除未使用函数/数据执行跨模块内联生成优化后的 ELF 对象最终链接优化后的对象与其他 ELF 对象和预编译库链接生成最终可执行文件6.3 LTO 对 Scatter FileTCM 放置的限制LTO 的核心问题是原始对象文件边界被打破对象合并LTO 将所有 bitcode 合并为 lto-llvm-xxxxx.o 这样的单一对象原始 .o 文件不再独立存在Section 属性丢失__attribute__((section(.dtcm))) 指定的段属性在 bitcode 合并过程中可能被合并或重命名Scatter 文件匹配失败scatter 文件中基于对象名的模式如 version.o (RO)将无法匹配产生 L6314W 警告具体表现问题说明对象名引用失效scatter 文件中无法使用 xxx.o 显式引用对象因为代码已被合并到 lto-llvm-xxxxx.oSection 属性可能被合并命名段可能无法在 bitcode 合并过程中保留RAM 函数放置异常通过 scatter 文件放入 RAM 的函数可能被内联到 Flash 函数中破坏原有放置Scatter-loading of LTO objects is supported but its recommended for code and data thatdoesnt have a strict placement requirement.— Arm Employee, Arm Community6.4 如何规避 LTO 限制方法操作换用 -Ofast不使用 -Omax避免 LTOscatter 文件正常工作部分文件禁用 LTO对需要严格放置的文件编译时加 -fno-lto其余文件保持 -flto链接器禁用 LTO使用 --no_lto 参数使用段名而非对象名scatter 文件中使用 *(.dtcm) 而非 xxx.o (.dtcm)不保证可靠6.5 本次测试中的体现配置 3-Omax fsp_tcm.scat与配置 4-Omax fsp.scat成绩相同2780.77说明LTO 开启后 scatter 文件的 TCM 放置可能未生效配置 5-Omax stack 放 DTCM达到最高 2974.97说明通过 __attribute__((section())) 直接指定 stack 位置的方式在 LTO 下仍然有效若需要 scatter 文件精确控制 TCM 放置建议使用 -Ofast 而非 -Omax七、总结AC6 优于 GCCAC6 基线成绩比 GCC 高约 27%编译器优化能力更强-Omax 最快但有代价LTO 带来额外 3-6% 性能提升但限制了 scatter 文件的 TCM 精确放置TCM 收益Stack 放入 DTCM 在两种工具链下都有正向收益AC6 下提升更明显最佳实践追求极致性能用 AC6 -Omax stack 放 DTCM6.20 CoreMark/MHz需要精确内存布局用 AC6 -Ofast