c++ - 有没有比添加 0.5f 和截断转换更直接的方法来将 float 转换为 int 并进行舍入？

Question

在处理浮点数据的 C++ 代码中，从 float 到 int 的舍入转换经常发生。例如，一种用途是生成转换表。

考虑这个代码片段:

// Convert a positive float value and round to the nearest integer
int RoundedIntValue = (int) (FloatValue + 0.5f);

C/C++ 语言将 (int) 转换定义为截断，因此必须添加 0.5f 以确保向上舍入到最接近的正整数(当输入为正时)。对于以上，VS2015的编译器生成如下代码:

movss   xmm9, DWORD PTR __real@3f000000 // 0.5f
addss   xmm0, xmm9
cvttss2si   eax, xmm0

上述工作，但可能更有效......

英特尔的设计者显然认为用一条指令解决一个问题已经足够重要了:转换为最接近的整数值:cvtss2si(注意，在助记符中只有一个“t”)。

如果 cvtss2si 替换上述序列中的 cvttss2si 指令，三个指令中的两个将被消除(就像使用额外的 xmm 寄存器一样，这可以导致更好的整体优化)。

那么我们如何编写 C++ 语句来使用一条 cvtss2si 指令完成这项简单的工作呢？

我一直在四处探索，尝试以下操作，但即使使用优化器执行任务，它也不能归结为可以/应该完成这项工作的一条机器指令:

int RoundedIntValue = _mm_cvt_ss2si(_mm_set_ss(FloatValue));

不幸的是，上述内容似乎倾向于清除永远不会使用的整个寄存器 vector ，而不仅仅是使用一个 32 位值。

movaps  xmm1, xmm0
xorps   xmm2, xmm2
movss   xmm2, xmm1
cvtss2si eax, xmm2

也许我在这里错过了一个明显的方法。

您能否提供一组建议的 C++ 指令，以最终生成单个 cvtss2si 指令？

Answer 1

这是微软编译器的优化缺陷，是微软的bug has been reported。正如其他评论者所提到的， modern versions of GCC, Clang, and ICC all produce the expected code 。对于像这样的函数:

int RoundToNearestEven(float value)
{
   return _mm_cvt_ss2si(_mm_set_ss(value));  
}

除了微软之外的所有编译器都将发出以下目标代码:

cvtss2si  eax, xmm0
ret

而 Microsoft 的编译器(从 VS 2015 Update 3 开始)发出以下内容:

movaps    xmm1, xmm0
xorps     xmm2, xmm2
movss     xmm2, xmm1
cvtss2si  eax,  xmm2
ret

double 版本 cvtsd2si(即 _mm_cvtsd_si32 内在函数)也是如此。
在优化器得到改进之前，没有更快的替代方案可用。幸运的是，当前生成的代码并不像看起来那么慢。移动和寄存器清除是最快的指令之一，其中一些可能可以作为寄存器重命名单独在前端实现。而且它肯定比任何可能的替代方案都快——通常是几个数量级:

您提到的添加 0.5 的技巧不仅会变慢，因为它必须加载常量并执行加法，而且在所有情况下也不会产生正确的舍入结果。

使用 _mm_load_ss 内在函数将浮点值加载到适合与 __m128 内在函数一起使用的 _mm_cvt_ss2si 结构中是一种悲观，因为它会导致内存溢出，而不仅仅是寄存器到寄存器的移动。
(请注意，虽然 _mm_set_ss 对于 x86-64 总是更好，其中调用约定使用 SSE 寄存器来传递浮点值，但我偶尔观察到 _mm_load_ss 将在 x86-32 构建中生成比 _mm_set_ss 更优化的代码，但它是高度取决于多个因素，并且仅在复杂的代码序列中使用多个内在函数时才会观察到。您的默认选择应该是 _mm_set_ss 。)

用 reinterpret_cast<__m128&>(value)(或道德等价物)代替 _mm_set_ss 内在函数既不安全又低效。它导致从 SSE 寄存器溢出到内存； cvtss2si 指令然后使用该内存位置作为其源操作数。

声明一个临时的 __m128 结构并对其进行值初始化是安全的，但效率更低。在堆栈上为整个结构分配空间，然后每个槽填充为 0 或浮点值。然后将此结构的内存位置用作 cvtss2si 的源操作数。

C 标准库提供的 lrint 系列函数应该可以满足您的需求，实际上在其他一些编译器上编译为简单的 cvt* 指令，但在 Microsoft 的编译器上是极其次优的。它们从不内联，因此您总是要支付函数调用的成本。另外，函数内部的代码是次优的。 Both of these 已经是 reported as bugs ，但我们仍在等待修复。标准库提供的其他转换函数也存在类似问题，包括lround和 friend 。

x87 FPU 提供了一条 FIST/FISTP 指令来执行类似的任务，但 C 和 C++ 语言标准要求强制截断，而不是舍入到最接近偶数(默认的 FPU 舍入模式)，因此编译器是有义务插入一堆代码来改变当前的舍入模式，执行转换，然后再改回来。这是非常慢的，并且没有办法指示编译器不要这样做，除非使用内联汇编。除了内联汇编在 64 位编译器中不可用这一事实之外，MSVC 的内联汇编语法也无法指定输入和输出，因此您需要支付双倍加载和存储代价。即使不是这种情况，您仍然需要支付将浮点值从 SSE 寄存器复制到内存，然后复制到 x87 FPU 堆栈的成本。

内部函数很棒，通常可以让您生成比编译器生成的代码更快的代码，但它们并不完美。如果您像我一样发现自己经常分析二进制文件的反汇编，您会发现自己经常感到失望。尽管如此，您最好的选择是使用内在函数。
至于为什么优化器以这种方式发出代码，我只能推测，因为我不在 Microsoft 编译器团队工作，但我的猜测是因为许多其他 cvt* 指令具有错误的依赖关系，即代码-generator 需要解决。例如，cvtss2sd 不会修改目标 XMM 寄存器的高 64 位。这种部分寄存器更新会导致停顿并减少指令级并行的机会。这在循环中尤其是一个问题，其中寄存器的高位形成了第二个循环携带的依赖链，即使我们实际上并不关心它们的内容。由于 cvtss2sd 指令在前一条指令完成之前无法开始执行，因此延迟大大增加。然而，通过首先执行 xorss 或 movss 指令，寄存器的高位被清除，从而打破依赖性并避免停顿的可能性。这是一个有趣的例子，其中较短的代码不等于更快的代码。编译器团队 started inserting these dependency-breaking instructions for scalar conversions in the compiler shipped with VS 2010 ，并且可能过度热情地应用了启发式方法。