gcc - 对于内联函数来说，什么是好的启发法？

Question

考虑到您只是尝试优化速度，那么决定是否内联函数的良好启发式是什么？显然代码大小应该很重要，但是当(例如)gcc 或 icc 确定是否内联函数调用时通常会使用其他因素吗？该领域是否有任何重要的学术工作？

Answer 1

维基百科有a few关于此的段落，底部有一些链接:

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

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

• Design, Implementation, and Evaluation of Optimizations in a Just-in-Time Compiler (针对 Java)讨论静态方法和动态加载类的方法内联及其对性能的改进。

• 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 ，里面讲了过于频繁内联函数的危险以及内联和宏的区别。编译器常常忽略程序员的内联如果他们可以确定这样做弊大于利，则请求；作为最后的手段可以使用宏来覆盖。)