为什么将 32 位寄存器移动到堆栈然后从堆栈移动到 xmm 寄存器？

Question

我正在 64 位机器上使用gcc -m32进行编译。

以下有什么区别？ 请注意，这是 AT&T 语法。

# this
movd  %edx, %xmm0

# and this
movl  %edx, (%esp)
movd  (%esp), %xmm0

Answer 1

机器状态的唯一区别是第二个版本在堆栈¹上留下了一个副本。

由于某种原因，GCC 的默认调整会在内存中反弹。 （最近的 GCC 可能已经在某些情况下修复了这个问题）。 大多数情况下，包括 AMD 在内的大多数 CPU 上的情况通常更糟，尽管 AMD 的优化手册确实推荐了它。 请参阅 GCC 错误80820和80833 re：GCC 的整数 <-> xmm 策略一般。

与存储和加载 uop 相比，使用movd将花费 1 个 ALU uop，因此前端的 uops 较少，但后端的 uops不同，因此根据周围的代码，存储/重新加载策略可以减轻压力特定的执行端口。

ALU movd延迟优于所有 CPU 上的存储/重新加载，因此存储/重新加载的唯一优势是可能的吞吐量。

Agner Fog在他为 Bulldozer（具有最慢movd %edx, %xmm0的 CPU）的microarch pdf 中说：

在我的测量中，整数单元和浮点/向量单元之间的传输延迟比 AMD 的软件优化指南中指定的要长得多。 尽管如此，我无法确认按照该指南中的建议，通过内存中间体将数据从通用寄存器移动到向量寄存器会更快。

---

脚注 1：如果您真的想要那样，单独的商店通常仍然是实现该状态的更好选择。 相同的 uops 数和更低的延迟（尤其是在 Intel CPU 上。AMD Bulldozer / Steamroller 的movd (x)mm, r32/r64有 10 / 5 个周期延迟movd (x)mm, r32/r64 1 个周期。）

movd %edx, %xmm0         # ALU int -> xmm transfer
movl %edx, (%esp)        # and store a copy if you want it