为什么 GCC 不使用部分寄存器？

Question

在linux上反汇编write(1,"hi",3)，用gcc -s -nostdlib -nostartfiles -O3构建会导致：

ba03000000     mov edx, 3 ; thanks for the correction jester!
bf01000000     mov edi, 1
31c0           xor eax, eax
e9d8ffffff     jmp loc.imp.write

我不参与编译器开发，但由于移入这些寄存器的每个值都是常量并且已知编译时间，我很好奇为什么 gcc 不使用 dl、dil 和 al。 有些人可能会争辩说，这个特性不会对性能产生任何影响，但是当我们谈论程序中的数千个寄存器访问时，mov $1, %rax => b801000000 和mov $1, %al => b001 之间的可执行文件大小存在很大差异。体积小不仅是软件优雅的一部分，而且对性能也有影响。

有人可以解释为什么“GCC 决定”它无关紧要吗？

Answer 1

是的，GCC 通常会避免写入部分寄存器，除非优化大小 (-Os) 而不是纯粹的速度 (-O3)。某些情况下需要至少写入 32 位寄存器才能确保正确性，因此更好的示例如下：

char foo(char *p) { return *p; } 编译为 movzx eax, byte ptr [rdi]
而不是mov al, [rdi]。 https://godbolt.org/z/4ca9cTG9j

但 GCC 并不总是避免部分寄存器，有时甚至会导致部分寄存器停顿https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15533

---

写入部分寄存器会导致许多 x86 处理器的性能损失，因为它们在写入时会被重命名为与整个对应寄存器不同的物理寄存器。 （有关寄存器重命名启用乱序执行的更多信息，请参阅this Q&A）。

但是当一条指令读取整个寄存器时，CPU 必须检测到它在单个物理寄存器中没有可用的正确架构寄存器值这一事实。 （这发生在问题/重命名阶段，因为 CPU 准备将 uop 发送到乱序调度程序。）

这称为部分寄存器停顿。 Agner Fog's microarchitecture manual 解释的很好：

6.8 部分寄存器停顿（PPro/PII/PIII 和早期的 Pentium-M）

部分寄存器停顿是当我们写入 32 位寄存器的一部分，然后从整个寄存器或更大部分读取时发生的问题。
示例：

; Example 6.10a. Partial register stall
mov al, byte ptr [mem8]
mov ebx, eax ; Partial register stall

这会产生 5 - 6 个时钟的延迟。原因是临时寄存器已 分配给AL，使其独立于AH。执行单元必须等到对AL 的写入退出后，才能将来自AL 的值与其余的值组合起来 EAX.

不同 CPU 中的行为：

• Intel 早期 P6 系列：见上文：停顿 5-6 个时钟，直到部分写入退出。
• Intel Pentium-M (model D) / Core2 / Nehalem：在插入合并微指令时停顿 2-3 个周期。 （见this Q&A for a microbenchmark writing AX and reading EAX with or without xor-zeroing first）
• 英特尔 Sandybridge：插入一个合并微指令用于低 8/低 16 (AL/AX) 而不停止，或用于 AH/BH/CH/DH，同时停止 1 个周期。
• Intel IvyBridge（可能），但肯定是 Haswell / Skylake：AL/AX 没有重命名，但 AH 仍然是： How exactly do partial registers on Haswell/Skylake perform? Writing AL seems to have a false dependency on RAX, and AH is inconsistent。
• 所有其他 x86 CPU：Intel Pentium4、Atom / Silvermont / Knight's Landing。所有 AMD（和 Via 等）：

部分寄存器永远不会被重命名。写入部分寄存器会合并到完整寄存器中，使写入依赖于完整寄存器的旧值作为输入。

如果没有部分寄存器重命名，如果您从未读取完整寄存器，则写入的输入依赖项是 false 依赖项。这限制了指令级并行性，因为从 CPU 的角度来看，将 8 位或 16 位寄存器重用于其他内容实际上并不独立（16 位代码可以访问 32 位寄存器，因此它必须在高位保持正确的值）一半）。而且，它使 AL 和 AH 不独立。当 Intel 设计 P6 系列（PPro 于 1993 年发布）时，16 位代码仍然很常见，因此部分寄存器重命名是使现有机器代码运行得更快的重要功能。 （实际上，许多二进制文件不会为新 CPU 重新编译。）

这就是编译器大多避免编写部分寄存器的原因。他们尽可能使用movzx / movsx 将窄值零或符号扩展到完整寄存器，以避免部分寄存器错误依赖（AMD）或停顿（Intel P6 系列）。因此，大多数现代机器代码并不能从部分寄存器重命名中受益，这就是为什么最近的 Intel CPU 正在简化其部分寄存器重命名逻辑。

As @BeeOnRope's answer points out，编译器仍然读取部分寄存器，因为这不是问题。 （不过，读取 AH/BH/CH/DH 会在 Haswell/Skylake 上增加一个额外的延迟周期，请参阅前面关于 Sandybridge 家族最近成员的部分寄存器的链接。）

---

另请注意 write 接受的参数对于 x86-64 通常配置的 GCC 需要完整的 32 位和 64 位寄存器，因此不能简单地将其组装成 @987654348 @。大小由数据的类型决定，而不是数据的值。

只有 32 位寄存器会隐式零扩展写入完整的 64 位；写入 8 位和 16 位部分寄存器保持高字节不变。 （这使得硬件难以有效处理，which is why AMD64 didn't follow that pattern。）

最后，在某些情况下，C 需要注意 default argument promotions，虽然不是这样。
实际上，正如RossRidge 指出的那样，调用可能是在没有可见原型的情况下进行的。

---

正如@Jester 指出的那样，您的反汇编具有误导性。
例如mov rdx, 3实际上是mov edx, 3，尽管两者的效果相同——即在整个rdx中放入3。
这是正确的，因为立即值 3 不需要符号扩展，并且 MOV r32, imm32 隐式清除寄存器的高 32 位。

Answer 2

在类似于原始 IBM PC 的设备上，如果已知 AH 包含 0，并且必须使用 0x34 之类的值加载 AX，则使用“MOV AL,34h”通常需要 8 个周期，而不是“”所需的 12 个周期MOV AX,0034h"——一个相当大的速度改进（如果预取指令可以在 2 个周期内执行，但实际上 8088 大部分时间都在等待以每个字节 4 个周期的成本获取指令） .然而，在当今通用计算机中使用的处理器上，获取代码所需的时间通常不是影响整体执行速度的重要因素，代码大小通常不是一个特别关注的问题。

此外，处理器供应商试图最大限度地提高人们可能运行的各种代码的性能，而如今 8 位加载指令的使用频率几乎不像 32 位加载指令那样频繁。处理器内核通常包括同时执行多个 32 位或 64 位指令的逻辑，但可能不包括同时执行 8 位操作和其他任何操作的逻辑。因此，虽然在可能的情况下在 8088 上使用 8 位运算是对 8088 的有用优化，但它实际上可能会显着消耗较新处理器的性能。

Answer 3

前面的三个答案都有不同的错误。

Margaret Bloom 接受的回答暗示部分寄存器停顿是罪魁祸首。部分寄存器停顿是真实的，但不太可能与 GCC 的决定相关。

如果 GCC 将 mov edx,3 替换为 mov dl,3，那么代码就是错误的，因为写入字节寄存器（与写入 dword 寄存器不同）不会将寄存器的其余部分归零。 rdx 中的参数是size_t 类型，即64 位，因此被调用者将读取完整的寄存器，其中将包含8 到63 位的垃圾。部分寄存器停顿纯粹是性能问题；如果错误，代码运行速度有多快并不重要。

可以通过在mov dl,3 之前插入xor edx,edx 来修复该错误。通过该修复，没有部分寄存器停顿，因为在所有有停顿问题的 CPU 中，使用 xor 或 sub 将完整寄存器归零然后写入低字节是特殊情况。所以部分寄存器停顿仍然与修复无关。

唯一与部分寄存器停顿相关的情况是，如果 GCC 碰巧知道寄存器为零，但它没有被特殊情况指令之一归零。例如，如果这个系统调用之前有

loop:
  ...
  dec edx
  jnz loop

然后 GCC 可以推断出 rdx 在它想要将 3 放入其中的点为零，而 mov dl,3 将是正确的 - 但一般来说这是一个坏主意，因为它可能导致部分寄存器摊位。 （在这里，这无关紧要，因为无论如何系统调用都很慢，但我认为 GCC 在其内部类型系统中没有“不需要对调用进行速度优化的慢功能”属性。）

---

如果不是因为部分寄存器停顿，为什么 GCC 不发出 xor 后跟字节移动？我不知道，但我可以推测。

它只在初始化r0 到r3 时节省空间，即使这样也只节省一个字节。它增加了指令的数量，这有其自身的成本（指令解码器通常是瓶颈）。与标准 mov 不同，它还破坏了标志，这意味着它不是直接替代品。 GCC 必须跟踪一个单独的标志破坏寄存器初始化序列，在大多数情况下（可能的目标寄存器的 11/15）会明显降低效率。

如果您正在积极优化大小，您可以执行push 3 后跟pop rdx，无论目标寄存器如何，都可以节省 2 个字节，并且不会破坏标志。但它可能要慢得多，因为它写入内存并且对rsp 有错误的读写依赖，而且节省空间似乎不太值得。 （它还修改了red zone，因此它也不是直接替换。）

---

超级猫的回答说

处理器内核通常包含同时执行多个 32 位或 64 位指令的逻辑，但可能不包含同时执行 8 位操作和其他任何操作的逻辑。因此，虽然在可能的情况下在 8088 上使用 8 位运算是对 8088 的有用优化，但它实际上可能会显着消耗较新处理器的性能。

现代优化编译器实际上大量使用 8 位 GPR。 （他们相对很少使用 16 位 GPR，但我认为这是因为 16 位数量在现代代码中并不常见。） 8 位和 16 位操作至少与 32 位和 64 位操作一样快执行阶段，有些更快。

我之前在这里写道：“据我所知，8 位操作在绝对每个 32/64 位 x86/x64 处理器上都与 32/64 位操作一样快，甚至更快。”但是我错了。相当多的超标量 x86/x64 处理器在每次写入时将 8 位和 16 位目标合并到完整寄存器中，这意味着当目标为 8/16 位时，像mov 这样的只写指令具有错误的读取依赖性当它是 32/64 位时不存在。如果您在每次移动之前（或期间，使用类似movzx 的东西）不清除寄存器，错误的依赖链可能会减慢执行速度。即使最早的超标量处理器（Pentium Pro/II/III）没有这个问题，较新的处理器也有这个问题。尽管如此，根据我的经验，现代优化编译器确实使用较小的寄存器。

---

BeeOnRope 的回答说

针对您的特定情况的简短回答是因为 gcc 在调用 C ABI 函数时总是将参数符号或零扩展为 32 位。

但是这个函数一开始就没有短于 32 位的参数。文件描述符正好是 32 位长，size_t 正好是 64 位长。这些位中的许多通常为零并不重要。如果它们很小，它们不是以 1 个字节编码的可变长度整数。如果 ABI 中没有整数提升要求，则仅使用 mov dl,3，rdx 的其余部分可能为非零是正确的，并且实际参数类型为 @987654350 @ 或其他一些 8 位类型。