Keil的编译器优化级别和调试视图

Keil的编译器优化级别和调试视图

Compiler User Guide: Compiler optimization levels and the debug view

编译器执行的精确优化取决于选择的优化级别,以及您是针对性能还是代码大小进行优化。

编译器支持以下优化级别:

0

最小优化。 关闭大多数优化。 启用调试时,此选项可提供最佳调试视图,因为生成的代码的结构直接对应于源代码。 所有干扰调试视图的优化都被禁用。 特别是:

  • 断点可以设置在任何可到达的点上,包括死代码。
  • 变量的值在其范围内的任何地方都可用,除非它未初始化。
  • 回溯提供读取源代码时预期的开放函数激活堆栈。

尽管 -O0 生成的调试视图与源代码最接近,但用户可能更喜欢 -O1 生成的调试视图,因为这样可以在不改变基本结构的情况下提高代码质量。

死代码包括对程序结果没有影响的可访问代码,例如对从未使用过的局部变量的赋值。 无法访问的代码具体是指无法通过任何控制流路径访问的代码,例如,紧跟在 return 语句之后的代码。

1

受限优化。 编译器只执行可由调试信息描述的优化。 删除未使用的内联函数和未使用的静态函数。 关闭严重降低调试视图的优化。 如果与–debug 一起使用,此选项可提供令人满意的调试视图,并具有良好的代码密度。
调试视图与 –O0 的不同之处在于:

  • 不能在死代码上设置断点。
  • 变量的值在初始化后可能在其范围内不可用。 例如,如果他们分配的位置已被重用。
  • 没有副作用的函数可能会被乱序调用,或者如果不需要结果则可能会被省略。
  • 由于尾调用的存在,Backtrace 可能无法提供预期从读取源代码中获得的开放函数激活堆栈。

优化级别 –O1 可在源代码和目标代码之间产生良好的对应关系,尤其是当源代码不包含死代码时。 生成的代码可以明显小于-O0 处的代码,这样可以简化对目标代码的分析。

2

高度优化。 如果与 --debug 一起使用,调试视图可能不太令人满意,因为目标代码到源代码的映射并不总是很清楚。 编译器可能会执行调试信息无法描述的优化。

这是默认的优化级别。
与 –O1 的调试视图的不同之处在于:

  • 源代码到目标代码的映射可能是多对一的,因为多个源代码位置映射到文件的一个点的可能性,以及更积极的指令调度。
  • 指令调度允许跨越序列点。 这可能会导致特定点处变量的报告值与您从阅读源代码中可能期望得到的值之间不匹配。
  • 编译器自动内联函数。

3

最大优化。 启用调试时,此选项通常会提供较差的调试视图。 ARM 建议在较低的优化级别进行调试。

如果同时使用 -O3 和 -Otime,编译器会执行更激进的额外优化,例如:

  • 高级标量优化,包括循环展开。 这可以以较小的代码大小成本提供显着的性能优势,但存在构建时间较长的风险。
  • 更激进的内联和自动内联。

这些优化有效地重写了输入源代码,导致目标代码与源代码的对应性最低,调试视图最差。 --loop_optimization_level=option 控制在 –O3 –Otime 执行的循环优化量。 循环优化的数量越高,源代码和目标代码之间的对应关系就越差。

有关在 –O3 –Otime 处对源代码执行的高级转换的额外信息,请使用 --remarks 命令行选项。

因为优化会影响目标代码到源代码的映射,所以选择带有 -Ospace 和 -Otime 的优化级别通常会影响调试视图。

如果需要简单的调试视图,选项 -O0 是最好的选择。 选择 -O0 通常会将 ELF 映像的大小增加 7% 到 15%。 要减少调试表的大小,请使用 --remove_unneeded_entities 选项。

posted @   木丨易  阅读(242)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!
点击右上角即可分享
微信分享提示