C++：编译器是否优化整数 + 浮点算术运算？答案

【问题标题】：C++: Do compilers optimize integer + float arithmetic operations?C++：编译器是否优化整数 + 浮点算术运算？
【发布时间】：2018-08-19 21:20:01
【问题描述】：

编译器是否有能力甚至能够优化一侧是整数类型而另一侧是浮点数的算术运算？还是会在 100% 的情况下将整数提升为浮点数，然后再执行操作？

我问的原因是因为为了清楚起见，我喜欢自己执行浮动提升，但如果它保留了编译器可以利用的情况，我可能会停止这样做。

【问题讨论】：

整数隐式转换为float的问题由标准回答，与优化无关
@UnholySheep：这个问题是有道理的，你的陈述并没有说明答案。虽然标准要求在抽象模型中将整数转换为浮点数，但编译器可以对加法执行某种优化，只要它得到相同的答案。所以这个问题本质上是问是否明确包括一个演员会阻止这种优化。
x86 可以直接操作 float,int 操作数，例如FIADD。演员表是不必要的，可能会影响性能。
@stark：演员阵容如何影响表演？如果得到与 C 要求相同的结果，编译器可以使用 FIADD 来添加浮点数和整数。 C 要求将整数转换为浮点数。因此，根据 C 标准，f + i 和 f + (float) i 必须具有相同的结果。因此，如果编译器在一种情况下可以使用FIADD，那么它可以在另一种情况下使用它。
因为如果按字面意思执行，它会先转换为浮点数，然后再进行浮点数相加。这是 x86 上的两条指令对比一条。

标签： c++ optimization compilation floating-point integer

【解决方案1】：

如果编译器可以优化 float 和整数之间的加法，例如将 3.f + 1 优化为 4 而不是在运行时执行加法，我希望存在强制转换对编译器能否优化没有影响。

这是基于现代编译器工作方式的一般性陈述，并非逻辑上的必要。在编译器识别出一些f + i 可以优化的情况下，对于一些float f 和一些整数i（可能是常量或表达式，而不仅仅是标识符），那么f + (float) i 应该在编译器的分析并且应该得到相同的优化。

理解为什么会这样的一种方法是，在解析 f + i 时，编译器将识别出 i 必须转换为 float，并且它将在程序的内部表示中构造语句以获取f，获取i，将i 转换为float，然后添加它们。在分析f + (float) i时，会构造相同的内部表示，所以这两个语句是等价的。

也就是说，我预计编译器可以优化的情况可能相当有限。编译器可以识别特定情况，例如添加两个常量、将float 零添加到整数以及将整数零添加到float。有时编译器可能能够推导出 f 和 i 的值，即使它们是表达式或标识符，而不是常量，因为先前代码的流必然会产生一些值，然后它可能能够基于推导出来的值。

因此，可能会识别特殊情况。我不希望编译器通常能够将f + i 转换为比浮点加法（或编译器通常使用的任何指令）更快的任何类型的优化位旋转。但是，从理论上讲，它可能会发生，如果是这样，一个设计良好的编译器应该优化 f + i 与 f + (float) i 相同。（也许有在软件而不是硬件中支持浮点的 C 实现，可能以比两个浮点值相加更快的方式处理浮点值和整数的相加。）

【讨论】：

【解决方案2】：

我也很好奇，所以我做了一些快速测试，并观察到以下行为：

这段代码的执行时间是：

for (int i = 0; i < 1000000000; ++i) {
    f = f + 1;
}

不带 -O2 标志：2156.25 ms
带 -O2 标志：953.125 ms

还有浮动促销：

for (int i = 0; i < 1000000000; ++i) {
    f = f + (float)1;
}

不带 -O2 标志：2156.25 ms
带 -O2 标志：968.75 ms

这只是一种情况。当然，这不是最好的检查方法，我确信编译器可以根据具体情况做得更好或更差，但我观察到优化 O2 的时间略有不同。

**在 c++11 中运行。 CPU架构：AMD64**

【讨论】：