英特尔编译器内联大小答案

【问题标题】：Intel compiler inline size英特尔编译器内联大小
【发布时间】：2021-04-29 13:08:35
【问题描述】：

我用g++ 编译我的代码已经有一段时间了，然后转移到英特尔的icpc 编译器。使用icpc，我不断收到以下警告：

remark #11074: Inlining inhibited by limit max-size 
remark #11074: Inlining inhibited by limit max-total-size

g++ 从来没有遇到过这个问题。经过一番研究，我了解到我可以使用-no-inline-max-total-size 和-no-inline-total-size 进行编译，以避免限制内联大小。我的问题是，尽可能多地删除内联和内联的大小是否总是一个好习惯？我的代码计算量很大，性能是关键，因此我的常识表明我应该允许编译器尽可能多的内联。真的吗？是否存在施加内联限制有用的情况？

【问题讨论】：

内联并不总是净收益，它会对性能产生负面影响。见this article。您不应该告诉编译器要内联什么。相信它比你更擅长决定内联的内容。除非您已经通过工具和测量证明强制内联是有益的，否则您不应该这样做。编译器可以通过as-if rule 内联它想要的任何内容。
谢谢！那么这是否意味着 g++ 编译器也有一些内联限制，只是没有发出任何警告？
@Botond：是的，完全正确。您可以使用 -finline-limit option 在 g++ 中调整此限制。如果您想在声明为inline 的函数未内联时收到通知，还有-Winline 选项。
我不太了解具体的编译器实现细节。有可能的。也许如果您共享了@987654324@，则可以比较编译器输出的程序集。

标签： c++ gcc inline icc

【解决方案1】：

我的问题是，尽可能多地删除内联和内联的大小是否总是一个好习惯？

不，消除内联的大小限制或尽可能多地内联并不总是一个好习惯。

理想情况下，内联应该只在提高性能时才进行。

在某些情况下施加内联限制是有用的吗？

如果一个函数非常大，并且从许多上下文中调用它，那么将此类函数内联到所有这些上下文将使可执行文件膨胀。如果可执行文件本身因为内联而有几千兆字节，那么从磁盘加载程序可能会成为瓶颈。

在不那么病态的情况下，权衡更加微妙。找出最佳极限的方法是测量。配置文件引导优化可以为优化器提供比简单的硬限制更有用的启发式方法。

【讨论】：