assembly - 为什么 Intel 的编译器更喜欢 NEG+ADD 而不是 SUB？

Question

在检查各种编译器的各种代码片段的输出时，我注意到英特尔的 C 编译器 (ICC) 有强烈倾向于发出一对 NEG+ADD 指令，其他编译器将使用单个 SUB 指令。

作为一个简单的示例，请考虑以下 C 代码:

uint64_t Mod3(uint64_t value)
{
    return (value % 3);
}

ICC 将其转换为以下机器代码(无论优化级别如何):

mov       rcx, 0xaaaaaaaaaaaaaaab
mov       rax, rdi
mul       rcx
shr       rdx, 1
lea       rsi, QWORD PTR [rdx+rdx*2]
neg       rsi                            ; \  equivalent to:
add       rdi, rsi                       ; /    sub  rdi, rsi
mov       rax, rdi
ret         

而其他编译器(包括 MSVC、GCC 和 Clang)都将生成本质上等效的代码，只不过 NEG+ADD 序列被替换为单个 SUB 指令。

就像我说的，这不仅仅是 ICC 编译这个特定代码片段的一个怪癖。这是我在分析算术运算的反汇编时反复观察到的一种模式。我通常不会对此想太多，除了众所周知 ICC 是一个非常好的优化编译器并且它是由了解其微处理器内部信息的人开发的。

英特尔是否了解有关 SUB 指令在其处理器上的实现的一些信息，从而可以更优化地将其分解为 NEG+ADD 说明？使用解码为更简单的微指令的 RISC 风格指令是现代微架构众所周知的优化建议，因此 SUB 是否有可能在内部分解为单独的 NEG 和 >ADD µops，前端解码器使用这些“更简单”的指令实际上更高效？现代CPU很复杂，所以一切皆有可能。

Agner Fog's comprehensive instruction tables不过，这证实了我的直觉，这实际上是一种悲观情绪。 SUB 在所有处理器上与 ADD 一样高效，因此额外所需的 NEG 指令只会减慢速度。

我还通过 Intel's own Architecture Code Analyzer 运行了两个序列来分析吞吐量。尽管确切的周期计数和端口绑定(bind)因微架构而异，但从 Nehalem 到 Broadwell，单个 SUB 似乎在各个方面都更胜一筹。以下是该工具为 Haswell 生成的两个报告:

子

Intel(R) Architecture Code Analyzer Version - 2.2 build:356c3b8 (Tue, 13 Dec 2016 16:25:20 +0200)
Binary Format - 64Bit
Architecture  - HSW
Analysis Type - Throughput

Throughput Analysis Report
--------------------------
Block Throughput: 1.85 Cycles       Throughput Bottleneck: Dependency chains (possibly between iterations)

Port Binding In Cycles Per Iteration:
---------------------------------------------------------------------------------------
|  Port  |  0   -  DV  |  1   |  2   -  D   |  3   -  D   |  4   |  5   |  6   |  7   |
---------------------------------------------------------------------------------------
| Cycles | 1.0    0.0  | 1.5  | 0.0    0.0  | 0.0    0.0  | 0.0  | 1.8  | 1.7  | 0.0  |
---------------------------------------------------------------------------------------

| Num Of |                    Ports pressure in cycles                     |    |
|  Uops  |  0  - DV  |  1  |  2  -  D  |  3  -  D  |  4  |  5  |  6  |  7  |    |
---------------------------------------------------------------------------------
|   1    | 0.1       | 0.2 |           |           |     | 0.3 | 0.4 |     | CP | mov rax, 0xaaaaaaaaaaaaaaab
|   2    |           | 1.0 |           |           |     |     | 1.0 |     | CP | mul rcx
|   1    | 0.9       |     |           |           |     |     | 0.1 |     | CP | shr rdx, 0x1
|   1    |           |     |           |           |     | 1.0 |     |     | CP | lea rax, ptr [rdx+rdx*2]
|   1    |           | 0.3 |           |           |     | 0.4 | 0.2 |     | CP | sub rcx, rax
|   1*   |           |     |           |           |     |     |     |     |    | mov rax, rcx
Total Num Of Uops: 7

求反+加

Intel(R) Architecture Code Analyzer Version - 2.2 build:356c3b8 (Tue, 13 Dec 2016 16:25:20 +0200)
Binary Format - 64Bit
Architecture  - HSW
Analysis Type - Throughput

Throughput Analysis Report
--------------------------
Block Throughput: 2.15 Cycles       Throughput Bottleneck: Dependency chains (possibly between iterations)

Port Binding In Cycles Per Iteration:
---------------------------------------------------------------------------------------
|  Port  |  0   -  DV  |  1   |  2   -  D   |  3   -  D   |  4   |  5   |  6   |  7   |
---------------------------------------------------------------------------------------
| Cycles | 1.1    0.0  | 2.0  | 0.0    0.0  | 0.0    0.0  | 0.0  | 2.0  | 2.0  | 0.0  |
---------------------------------------------------------------------------------------

| Num Of |                    Ports pressure in cycles                     |    |
|  Uops  |  0  - DV  |  1  |  2  -  D  |  3  -  D  |  4  |  5  |  6  |  7  |    |
---------------------------------------------------------------------------------
|   1    | 0.1       | 0.9 |           |           |     | 0.1 | 0.1 |     |    | mov rax, 0xaaaaaaaaaaaaaaab
|   2    |           | 1.0 |           |           |     |     | 1.0 |     | CP | mul rcx
|   1    | 1.0       |     |           |           |     |     |     |     | CP | shr rdx, 0x1
|   1    |           |     |           |           |     | 1.0 |     |     | CP | lea rax, ptr [rdx+rdx*2]
|   1    |           | 0.1 |           |           |     | 0.8 | 0.1 |     | CP | neg rax
|   1    | 0.1       |     |           |           |     | 0.1 | 0.9 |     | CP | add rcx, rax
|   1*   |           |     |           |           |     |     |     |     |    | mov rax, rcx
Total Num Of Uops: 8

所以，据我所知，NEG+ADD增加了代码大小，增加了微指令的数量，增加了执行端口的压力，并增加了数量周期，从而导致与 SUB 相比吞吐量净下降。那么为什么英特尔的编译器要这样做呢？

这只是代码生成器的一些怪癖，应该报告为缺陷，还是我在分析中遗漏了一些优点？

Answer 1

奇怪的是，我有一个简单的答案:因为 ICC 不是最佳的。

当您编写自己的编译器时，您会开始使用一些非常基本的操作代码集:NOP、MOV、ADD...至 10 个操作码。您暂时不会使用 SUB，因为它很容易被:ADD NEGgative operand 替换。 NEG 也不是基本的，因为它可能被替换为:XOR FFFF...;添加1。

因此，您实现了相当复杂的基于位的操作数类型和大小寻址。您为单个机器代码指令(例如ADD)执行此操作，并计划将其进一步用于大多数其他指令。但此时您的同事已完成余数优化计算的实现，而无需使用 SUB!想象一下 - 它已经被称为“Optimal_Mod”，所以你错过了一些内部不优化的东西，不是因为你是一个坏人并且讨厌 AMD，而是因为你看到 - 它已经被称为最佳的、优化的。

英特尔编译器总体来说相当不错，但它有很长的版本历史，因此在某些罕见的情况下它可能会表现得很奇怪。我建议您将此问题告知英特尔，看看会发生什么。