内联函数有什么好的启发式方法？

Question

考虑到你只想优化速度，有什么好的启发式方法来决定是否内联一个函数？显然，代码大小应该很重要，但当(比方说) gcc或icc决定是否内联函数调用时，是否有其他通常使用的因素？在这个领域有什么重要的学术研究吗？

Answer 1

维基百科有关于这一点的a few段落，底部有一些链接：

• 除了内存大小和缓存问题外，还有another consideration is register pressure。从编译器的角度来看，“来自内联过程的添加变量可能会消耗额外的寄存器，并且在寄存器压力已经很高的区域，这可能会强制溢出，从而导致额外的内存访问。”

带有JIT编译器和运行时类加载的语言有其他权衡，因为虚拟方法不是静态已知的，但JIT可以收集运行时分析信息，如方法调用频率：

• Design, Implementation, and Evaluation of Optimizations in a Just-in-Time Compiler (for Java)讨论了静态方法和动态加载类的方法内联，它对performance.
• Practicing JUDO: Java Under Dynamic Optimizations的改进声称他们的“内联策略是基于代码大小和概要信息的。如果方法条目的执行频率低于某个阈值，则该方法不会被内联，因为它被视为冷方法。为了避免代码爆炸，我们不内联字节码大小超过25字节的方法。。。。为了避免沿深层调用链进行内联，当沿调用链累积的内联字节码大小超过40个字节时，内联就会停止。“尽管它们有运行时分析信息(方法调用频率)，但它们仍然小心地避免内联大型函数或函数链，以防止膨胀。

A search on Google Scholar揭示了许多论文，例如

• The effect of code expanding optimizations on instruction cache design
• Function Inlining under Code Size Constraints for Embedded Processors

A search on Google Books透露了相当多的书籍，其中有关于各种上下文中函数内联的论文或章节。

• The Compiler Design Handbook: Optimizations and Machine Code Generation有一章介绍了编译器设计中的统计和机器学习技术，并使用启发式方法设置各种参数，分析结果。本章引用了Vaswani等人的论文Microarchitecture Sensitive Empirical Models for Compiler Optimizations，其中他们提出了“使用经验建模技术为编译器构建微体系结构敏感模型”其他书籍从程序员的角度讨论了内联，例如C++ for Game Programmers，它谈到了过于频繁地内联函数的危险以及内联和宏之间的区别。如果编译器可以确定内联请求弊大于利，则编译器通常会忽略程序员的内联请求；这可以作为最后的手段用宏覆盖。)

Answer 2

函数调用意味着一些额外的代码(函数序号，设置新的堆栈框架的位置，以及函数结尾处，它被清除)。如果您的编译器发现函数代码与前言和结尾相比较小，它可以确定不值得进行实际调用，并将内联函数。

我认为调用函数而不是内联函数的唯一好处是与大小相关。我猜内联一个函数，然后展开一个循环可能会导致一个显着的大小增加。

Answer 3

据我所知，函数大小是编译器用来确定内联的唯一因素。然而，如果你做了概要引导优化(PGO)，我相信编译器能够使用其他变量，比如调用次数/调用建立时间。