我可以合理地期望编译器能够内联吗？

Question

我是否可以使用任何通用规则来评估现代编译器是否会内联函数？额外堆栈帧的相对成本是多少（我知道它非常小，但是有没有办法对它进行一般量化 - 大概在一个数量级左右）？

我也特别感兴趣：

• 可以在cpp？
中定义编译器内联方法
• 我知道有些编译器甚至在调试时也实现了一些优化（VS在调试中使用RVO而不是NRVO） - 内联的情况是什么？我想它已被禁用，以便我们可以看到预期的调用堆栈以进行调试。

我目前正在尝试对内存跟踪系统进行微优化，特别是那些在未启用优化的情况下也适用的内存跟踪系统（在调试中）。

Answer 1

很容易预测，很难预测。简单的表达式，如：

int a = b + (2 * c):
int d = e + (2 * c);

使用最简单的优化进行优化（(2 * c)“公共子表达式”只会计算一次。

在C / C ++中，内联声明的方法通常是（但并不总是）。

Trickier是循环优化等。例如，

for (int i = 1; i < n; i++) {
    a = i + (2 * c);
}

表达式(2 * c)通常会在执行“全局优化”的编译器中退出循环，但不会只执行“局部优化”。而且，当然，表达式会变得更加复杂和复杂。

将上述循环的主体更改为a = i * (2 * c);，然后进入稍高级别的全局优化，称为“循环归纳”。对于循环中的每次迭代，“智能”编译器只会将2 * c（作为预计算）添加到a，而不是在每次迭代时进行（更昂贵的）乘法。

这只是表面上的问题。

但我不知道Visual Studio编译器能够做什么。