在G ++中，优化级别-O3危险吗？

我从各种来源（尽管大部分是我的同事发来的）都听说过，-O3用g ++ 的优化级别进行编译在某种程度上是“危险的”，除非被证明是必要的，否则通常应该避免编译。

这是真的吗？如果是这样，为什么？我应该坚持-O2吗？

在gcc的早期（2.8等）和egcs时代，redhat 2.96 -O3有时是相当多的错误。但这是十年前的事了，-O3与其他级别的优化（在儿童车方面）没有太大不同。

但是，它确实倾向于揭示人们依赖未定义行为的情况，这是由于更严格地依赖一种或多种语言的规则，尤其是极端情况。

作为个人说明，我使用-O3在金融领域运行生产软件已有很多年了，并且还没有遇到过如果我使用-O2就不会出现的错误。

根据大众需求，这里有一个补充：

-O3尤其是诸如-funroll-loops之类的其他标志（未由-O3启用）有时会导致生成更多机器代码。在某些情况下（例如，在具有极小L1指令高速缓存的CPU上），这可能会导致速度变慢，这是因为某些内部循环的所有代码现在不再适合L1I。通常，gcc会尽力避免不生成太多代码，但是由于它通常会优化通用情况，因此可能会发生这种情况。-O3中通常不包括特别容易出现的选项（例如循环展开），并在手册页中进行了相应标记。因此，通常最好使用-O3来生成快速代码，并且仅在适当的时候（例如，当探查器指示L1I未命中时）回退到-O2或-Os（尝试对代码大小进行优化）。

如果您想将优化发挥到极致，则可以通过--param调整gcc与某些优化相关的成本。另外请注意，gcc现在可以将属性放在控制仅针对这些功能的优化设置的功能上，因此，当您发现一个功能中存在-O3问题时（或想尝试该功能的特殊标志），您无需使用O2编译整个文件甚至整个项目。

在使用-Ofast时，似乎必须小心，它指出：

-Ofast启用所有-O3优化。它还启用了并非对所有符合标准的程序都有效的优化。

这使我得出结论，-O3旨在完全符合标准。

根据我的经验，应用-O3到整个程序几乎总是会使它变慢（相对于-O2），因为应用程序会打开积极的循环展开和内联程序，从而使程序不再适合指令高速缓存。对于较大的程序，-O2相对于-Os！也是如此。

预期的使用模式-O3是，在对程序进行性能分析后，将其手动应用于少量文件，这些文件包含一些关键的内部循环，而这些循环实际上可以从这些积极的速度比空间取舍中受益。较新版本的GCC具有配置文件引导的优化模式，该模式可以（IIUC）有选择地将-O3优化应用于热功能-有效地使此过程自动化。

除较低级别“ -O2”和“ -O1”的所有优化外，-O3选项还会启用更昂贵的优化，例如函数内联。'-O3'优化级别可以提高生成的可执行文件的速度，但也可以增加其大小。在某些情况下，这些优化不令人满意，此选项实际上会使程序变慢。

是的，O3令人讨厌。我是一名编译器开发人员，而且我已经确定由O3引起的清晰明显的gcc错误，这些错误是由O3在构建自己的软件时生成错误的SIMD汇编指令引起的。据我所知，大多数生产软件都附带O2，这意味着O3在测试和错误修复方面的关注度会降低。

这样想：O3在O2之上添加了更多的转换，在O1之上添加了更多的转换。从统计上讲，更多的转换意味着更多的错误。对于任何编译器都是如此。

最近，我在使用优化时遇到了一个问题g++。问题与PCI卡有关，其中的寄存器（用于命令和数据）由内存地址表示。我的驱动程序将物理地址映射到应用程序中的指针，并将其提供给被调用的进程，该进程以如下方式工作：

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

该卡未按预期运行。当我看到程序集时，我知道编译器仅someCommand[ the last ]写入pciMemory，而忽略了之前的所有写入。

结论：准确，专心于优化。