c - 内联 C 代码 : -flto or not -flto

Question

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

不幸的是，虽然 Visual 非常擅长此练习，但 gcc 和 clang 却不是。显然，由于热门函数位于不同的 .c 中，因此无法内联它们。

这给我留下了 2 个选择:

• 要么直接将相关代码包含到目标文件中。实际上，这意味着 #include "perf.c" 而不是 #include "perf.h"。微不足道的变化，但它看起来很难看。显然它有效。向构建链解释 perf.c 必须存在但不被编译或链接会稍微复杂一些。

• 使用 -flto 进行链接时间优化。它看起来更干净，并且是 Visual 默认实现的。

  问题是，使用 -flto，gcc 链接阶段会生成多个警告，seem to be internal bugs (它们指的是标准库中的部分代码，所以我对它们几乎没有控制权)。这在针对“零警告”策略时很尴尬(即使生成的二进制文件非常好)。

  至于 clang，由于打包错误(错误加载插件:LLVMgold.so)，它只是以 -flto 失败，这显然在多个 linux 发行版中很常见。

  <

2 个问题:

1. 有没有办法在 gcc 上使用 -flto 时关闭这些警告消息？
2. 考虑到优缺点，上述两种方法中哪一种似乎更好？
3. 可选:是否有其他解决方案？

Answer 1

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

因此，当然，#include 代码要格外小心。

更新:

文件扩展名不应该是 .c，但是，例如.inc(.i 也是个坏主意)。更好的是:.h 并将函数更改为 static inline。这仍然可能无法保证内联，但这与所有函数相同，并且它保持了干净的 header 外观(尽管更长的 inline 函数仍然是不好的风格)。

在执行所有这些操作之前，如果代码真的 有问题，我会进行适当的剖析。首先应该专注于编写可读和可维护的代码。