[参考译文] Arm-CGT：TI-CGT-ARM 20.2.7编译器优化

您好！

 TI ARM 编译器手册的"调用优化"子章节介绍了这些效果。  禁用优化时、更高级别的优化将被完全禁用。  这些优化对生成的代码影响最大。  但是、有一些特定于目标的低级别优化是在优化器之外完成的、这些优化是由所选的特定速度与尺寸权衡决定的、但实际上不如启用更高级别优化时那么有效。  之所以设置这些链接、是因为编译器必须做出目标级选择、但这些选择可能仍会无意中影响代码大小或性能、因此用户可以根据需要对其进行调整。  通常、我们 建议使用默认设置。

-艾伦

您好、Alan：

我们以航空应用为基础、因此它具有高安全性。 我们需要知道要对代码进行哪些优化？ 有可能吗？  

嗨穆罕默德--我的语言是不精确的,因为这些低级别,目标特定的"优化"领域真正的目标级别的选择,编译器必须作出。 没有提供这些选项的列表。  为安全起见、专注于更高级别的优化、这些优化会对生成的代码(此处已禁用)产生广泛的影响。  这些优化列在上面链接的编译器手册中。

Alan、您好、我无法回答我的问题是、当我们选择 opt_for_speed = 0时、是否会对代码大小产生影响？ 或者是否进行了任何优化？ 如果编译器在设置为 speed = 0时进行优化、则需要知道优化对代码有何影响。

我想你的总体目标是...

Unknown 说：

]关闭所有编译器优化

当然、实现该目的的主要方法是使用设置 -- opt_level=off .  因为该选项 -- opt_for_speed 在相同的选项对话框中、您假设有某种方法将其关闭。  以这种方式来思考是没有意义的。

大多数优化会去除指令、从而提高速度和大小。  但是、还有一些优化可以在改进一个选项的同时降低另一个选项的性能。  两个出色的示例是函数内联和循环展开。  因此、用户可以控制 此类优化的速度与大小权衡、编译器支持该选项 -- opt_for_speed= 电流。  较低的值倾向于较小的尺寸、但代价是速度较慢。  值越高、速度越快、但代价是尺寸越大。  没有对应于关闭的设置。

最有意义的方法是使用与编译器默认时间相对应的设置 -- opt_for_speed 未指定。  该设置 -- opt_for_speed=1 .

谢谢。此致、

-George.

欢迎您拒绝我标记为"已解决"的回复。  但在我进一步答复之前,我需要知道你为什么拒绝它。

谢谢。此致、

-George.

您好、George：

首先、很抱歉无法回复您的消息。

拒绝的原因是您的回答不适合我。 因为、如果我继续使用默认值、我将对代码进行了优化。 但正如我上面提到的,我不希望除了我在安全应用上为航空开发的软件中编写的代码之外,还有一个软件。 所以你的答案是不够的和无效的。

此外、如您所知、诸如 TMS570之类的处理器是专为安全关键任务而开发的。 但我们要为此处理器嵌入的代码建议进行优化。 你不认为有矛盾吗?

关闭安全关键型软件中的优化应由用户控制。

Unknown 说：

因为、如果我继续使用默认值、我将优化我的代码。

如果这就是优化的含义、那么无论使用何种选项、所有编译器都会进行优化。

假设编译器没有该选项、这正是一个深思熟虑的实验 -- opt_for_speed .  进一步假定编译器实现者没有明确考虑在大小和速度之间进行权衡。  即使在这些不切实际的条件下、仍然可以在尺寸和速度之间进行选择。  因为无法避免该选择。  TI Arm 编译器不仅会明确地进行此折衷、还为用户提供了一种通过选项来影响此折衷的方法 -- opt_for_speed .

谢谢。此致、

-George.

您也无法控制编译器如何将 C 代码转换为汇编代码(即使不进行优化)。 这也可能很容易出现故障。

和编译器*始终*进行无提示优化、例如编译时常数计算。

我不同意您的"所有编译器优化"响应。 因为我们可以在 TI-Clang 编译器中关闭优化关闭。

那么,在"编程风格的元素", ca 1978, Kernigham 和 Plauger 说:

"许多编译器甚至无需要求就可以对将常量移出循环进行简单的优化。 (了解过多、您甚至可能会阻碍他们的努力。) 但是、即使对于具有简单思想的编译器、前两行[I = K+1；Temp = C (I)]肯定也应该组合为 Temp = C (K+1)。"

Unknown 说：

我们可以在 TI-Clang 编译器中关闭优化功能

tiarmclang -O0 和 armcl --opt_level=off 非常相似、因为它们禁用了所有大规模优化。  但这两个选项都不会禁用100%的编译器优化。  所有其他编译器在这方面都非常相似。

谢谢。此致、

-George.