内联 C 代码：-flto 或不 -flto答案

【问题标题】：inlining C code : -flto or not -flto内联 C 代码：-flto 或不 -flto
【发布时间】：2015-07-05 01:03:10
【问题描述】：

我最近的一个程序高度依赖内联一些“热门”函数来提高性能。这些热函数是外部.c 文件的一部分，我不想更改。

不幸的是，虽然 Visual 非常擅长这个练习，但 gcc 和 clang 却不是。显然，由于热函数在不同的.c 中，它们不能内联它们。

这让我有两个选择：

要么直接将相关代码包含到目标文件中。实际上，这意味着#include "perf.c" 而不是#include "perf.h"。微不足道的变化，但看起来很难看。显然它有效。向构建链解释 perf.c 必须存在但不能编译或链接，这有点复杂。
使用-flto，进行链接时间优化。它看起来更干净，是 Visual 默认实现的。

问题是，对于-flto，gcc 链接阶段会生成多个警告，其中seem to be internal bugs（它们指的是标准库中的部分代码，因此我几乎无法控制它们）。当针对“零警告”策略时，这是令人尴尬的（即使生成的二进制文件非常好）。

至于 clang，由于打包错误（错误加载插件：LLVMgold.so）导致 -flto 失败，这显然在多个 linux 发行版中很常见。

2 个问题：

【问题讨论】：

通常包含内联函数的文件被赋予.inl 扩展名，并在相应标题的底部添加#included。
错误报告说它已被修复。是否可以尝试使用最新的 binutils？
请说明工具的版本。
@blueMoon ：不是真的。只为我解决问题不是一种选择。它应该适用于具有不同构建链的其他团队，我无法控制，因此不可能依赖过于特定的版本。除此之外，还有clang的pb...
@olaf ：我已经用 gcc 4.8.4 和 clang 3.4 进行了测试。但正如之前评论中所说，我需要支持更广泛的配置。

【解决方案1】：

根据您的评论，您必须支持 gcc 4.4。由于 LTO 从 gcc 4.5 开始（对早期版本非常谨慎），答案应该很清楚。 没有-flto。

所以，#include 代码当然要小心谨慎。

更新：

文件扩展名不应该是.c，但是，例如.inc（.i 也是个坏主意）。更好的是：.h 并将函数更改为 static inline。这可能仍然不能保证内联，但对于所有函数来说都是一样的，并且它保持了一个干净的标题的外观（尽管更长的 inline 函数仍然是不好的风格）。

在做这一切之前，我会正确分析，如果代码真的有问题。首先应该专注于编写可读和可维护的代码。

【讨论】：