c++ - GCC 4.6.2 内联行为

Question

-- 从 chat.so 中截取的 --

在使用 intel VTune 进行分析后，我在某个项目中陷入了 gcc 4.6.2 的困境我注意到非常微不足道的函数没有被内联(或者至少出现在热点下，我认为这意味着内联失败)

示例函数是重新解释转换、2 个数字加法和一个三元语句

我相信这些在 Windows 中内联，但由于分析，认为它们没有在 gcc 4.6.2 下的 Linux 中内联

我正在尝试让 ICC 构建在 Linux 中工作(在 Windows 中工作)，但这需要一些时间

到那时，有谁知道 GCC 4.6.2 在相对简单的编译器优化方面是否与 VS2010 不同？我已在 GCC 中打开 -O3

导致我这样做的原因是，这是对重要代码部分的重写，在 Windows 上，性能大致相同或稍慢一些，而在 Linux 上，速度至少慢 2 倍。

信息最丰富的答案将帮助我了解验证跨平台内联所需的步骤，以及如何最好地处理这种情况，因为我知道这些事情是非常具体的。

编辑:此外，假设特定于业务的原因迫使我坚持使用 GCC 4.6.2，那么在不重写代码以使其不易维护的情况下我该怎么办？

谢谢!

Answer 1

首先是非常明显的完整性:您是否绝对确定执行可能非内联调用的所有文件都是使用 -O3 编译的？

gcc 和 VS 编译器和工具链有很大的不同，如果它们的优化器表现得相当不同，我一点也不会感到惊讶。

接下来让我观察一下三元运算符可能非常具有欺骗性。三元运算符几乎肯定会创建一个分支，并可能创建构造函数调用、转换等。不要假设仅仅因为它是 C++ 中的简洁运算符，编译器就能够为其生成少量代码。这可能会阻止编译器对其进行优化。事实上，您可以尝试将三进制代码重新编写为正常的 if声明，看看这是否对你的表现有帮助。

然后，一旦您开始进一步诊断，一个简单的尝试就是使用 strings <binary> | grep function并查看函数名称是否出现在二进制文件中。如果没有，那么它肯定是内联的(尽管即使它显示出来，它也可能是严格的调试信息而不是实际的代码)。还有其他工具如nm , readelf , elfdump ，和dump它也可以内省(introspection)二进制文件中的符号。您需要查看您的平台上有哪些工具可用，然后尝试使用它们来查找有问题的功能。

另一个想法是将编译后的二进制文件加载到 gdb 中，并要求它 dis在文件中汇编代码，并在函数call发生的地方汇编代码。然后你可以阅读反汇编代码来看看编译器做了什么。大多数代码实际上应该相当明显。您可能会看到类似 call 的内容指令是否进行了实际的函数调用。