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

在处理浮点数据的 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));

不幸的是，上面的内容似乎一心想要清除一整个永远不会使用的寄存器向量，而不是仅仅使用一个 32 位值。

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

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

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

这是微软编译器的一个优化缺陷，该bug已经被报告了 https://connect.microsoft.com/VisualStudio/feedback/details/3118553到微软。正如其他评论员提到的，现代版本的 GCC、Clang 和 ICC 都会生成预期的代码 https://godbolt.org/g/hyWUct。对于这样的函数：

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

除 Microsoft 之外的所有编译器都会发出以下目标代码：

cvtss2si  eax, xmm0
ret

而 Microsoft 的编译器（截至 VS 2015 Update 3）会发出以下内容：

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

双精度版本也是如此，cvtsd2si (i.e., the _mm_cvtsd_si32固有的）。

在优化器得到改进之前，没有更快的替代方案可用。幸运的是，当前生成的代码并不像看起来那么慢。移动和寄存器清除是最快的指令之一，其中一些指令可能可以仅在前端作为寄存器重命名来实现。它是当然比任何可能的替代方案都要快——通常快几个数量级：

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

• 使用_mm_load_ss将浮点值加载到一个固有的__m128结构适合与使用_mm_cvt_ss2si内在是一种悲观，因为它会导致内存溢出，而不仅仅是寄存器到寄存器的移动。

  （请注意，虽然_mm_set_ss is always对于 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.

• The lrintC 标准库提供的函数系列应该可以满足您的需求，并且实际上可以编译为简单的cvt*一些其他编译器上的指令，但在 Microsoft 编译器上极其次优。它们永远不会内联，因此您总是要付出函数调用的成本。另外，函数内部的代码不是最优的。这两个 https://connect.microsoft.com/VisualStudio/feedback/details/1089355/cq-lrintf-doesnt-optimize-to-a-single-instruction-regardless-of-settings已经报告为错误 https://connect.microsoft.com/VisualStudio/feedback/details/1179496/vc-lrintf-is-376-times-longer-than-gcc-clang-version，但我们仍在等待修复。标准库提供的其他转换函数也存在类似的问题，包括lround和朋友。

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

内部函数很棒，通常可以让您生成比编译器生成的代码更快的代码，但它们并不完美。如果您像我一样，发现自己经常分析二进制文件的反汇编，您会发现自己经常感到失望。不过，这里最好的选择是使用内在函数。

As for why优化器以它的方式发出代码，我只能推测，因为我不在 Microsoft 编译器团队工作，但我的猜测是因为许多其他cvt*指令具有代码生成器需要解决的错误依赖性。例如，一个cvtss2sd不修改目标 XMM 寄存器的高 64 位。这样的partial寄存器更新会导致停顿并减少指令级并行的机会。这在循环中尤其是一个问题，其中寄存器的高位形成第二个循环携带的依赖链，即使我们实际上并不关心它们的内容。因为执行cvtss2sd直到前面的指令完成后，指令才能开始，延迟大大增加。但是，通过执行xorss or movss首先，寄存器的高位被清除，从而打破依赖性并避免停顿的可能性。这是一个有趣的案例的例子shorter代码不等于faster代码。编译团队开始在 VS 2010 附带的编译器中插入这些用于标量转换的破坏依赖性的指令 https://blogs.msdn.microsoft.com/vcblog/2009/11/02/visual-c-code-generation-in-visual-studio-2010/，并且可能过度热衷于应用启发式。