什么是部分标志位？

Question

我刚刚检查了this answer by Peter Cordes，他说，

部分标志停顿在读取标志时发生，如果它们发生的话。 P4 从来没有部分标志停顿，因为它们永远不需要被合并。相反，它具有错误的依赖关系。几个答案/ cmets 混淆了术语。他们描述了一个错误的依赖关系，但随后将其称为部分标志停止。这是由于仅写入一些标志而发生的减速，但术语“部分标志停顿”是在必须合并部分标志写入时在前 SnB 英特尔硬件上发生的情况。 Intel SnB 系列 CPU 插入一个额外的 uop 以合并标志而不会停止。 Nehalem 和更早的版本停滞了约 7 个周期。我不确定 AMD CPU 的损失有多大。

我觉得我还不明白什么是“部分旗帜摊位”。我怎么知道发生了什么？读取标志时，除了有时之外，还有什么触发事件？合并标志是什么意思？在什么情况下“写入了一些标志”但不发生部分标志合并？我需要了解哪些关于旗帜摊位的知识才能理解它们？

Answer 1

修改 uop 的标志只能更新标志寄存器的一部分。 RAT 有一个用于 flags/eflags/rflags 寄存器的条目和一个掩码，该掩码显示由 uop 更改的标志，这些标志导致该条目指向的物理寄存器被分配。如果发生一系列读取和写入相同标志的指令，则为每次写入分配一个单独的物理寄存器，并且每次读取都使用前一个物理寄存器。在这些寄存器中将写入该标志，并且所有其他标志都将被清除。这就是为什么当从不在标志 RAT 条目中的掩码中的不同标志读取时不能使用当前物理寄存器的原因，因为它会读取一个清除位而不是已留下的标志的真实状态。在旧的微架构上，会发生停顿，直到标志寄存器的状态在 RRF 中有效（通过等待每个标志设置 uop 的退出，然后再插入它们在 RRF 标志寄存器中设置的位，其中每个 uop 被检查以知道它使用的架构寄存器/它改变的标志，这是一种比 x86 宏操作更容易解释的格式。

在使用 PRF 方案（SnB 以上）的微架构上，当没有专用的 RRF 寄存器时，需要一个合并的 uop 来保持一个统一的标志寄存器，否则退休 RAT 将指向一个无意义的物理寄存器，只有 1 个中的标志。合并 uop 发生在每个部分标志修改指令之后，如 inc 或 dec。 add 修改所有 6 个状态标志，因此不需要合并微指令。我认为这可能意味着状态、控制和系统标志在 PRF 方案上分别重命名，因为 add 不需要合并 uop。显然 CF 标志是renamed differently to the SPAZO cluster。

部分寄存器停顿是类似的。 The RAT has 2 entries to represent rax: an entry for al/ax/eax/rax (distinguished by a size indicator in the entry) and ah（在写入ax、eax 或rax 时都会更新以指向同一个寄存器）。因为只有2个互斥寄存器，所以只需要2个就可以表示。如果对eax 的读取发生在对较小寄存器之一的先前写入退出之前，则分配器停止（因为 ROB 条目不能对同一操作数有 2 个依赖项），直到 RRF 中存在完整的寄存器，然后它会将这两个条目重命名为 rax 的 RRF 寄存器。

在后来使用 PRF 方案的微架构中，这现在很困难，因为不再保留用于 rax 的单个 RRF。所以需要使用merging uop，也恰好比之前微架构的stall方式快。

合并 uop 实现

1. 合并微指令的一种实现可能是在每次写入部分标志/寄存器之前插入它，并且合并微指令在将其全部写入新的物理寄存器之前从完整寄存器/标志寄存器中读取。然后为写入分配相同的寄存器，这导致写入自然地合并到其中。随后的读取可以读取寄存器的任何部分/任何标志。这基本上在每个部分标志写入指令和之前的标志写入指令（部分或完整）之间以及在每个部分寄存器写入和之前（完整/部分）写入寄存器之间建立了依赖链。在这种情况下，RAT 永远不会有部分重命名。

2. 它可以在写入部分寄存器后立即分配。合并微指令采用前一个物理寄存器（始终是完整的rax/eax 写入，或者在标志的情况下，完整的状态标志更新，就像add 或合并微指令所做的那样）和新的物理寄存器并将它们组合到新的物理寄存器中。这表明分配器插入它。如果它是由解码器插入的，则分配器可以在前一个 RAT 指针未知时在不同的周期中分配该 uop。

3. 它可以在从 RAT 中具有统一状态的寄存器读取之前立即分配。这意味着 RAT 分别跟踪 rax/eax 到 ax、al 和 ah。在这种情况下，需要合并的2个物理寄存器取自RAT。

优化手册暗示它是后两种情况之一“合并 uop 在每次部分寄存器写入之后发生”（即写入 ax、al 或 ah、but not eax）。

Answer 2

一般来说，当使用标志的指令读取一个或多个不是由最近的标志设置指令写入的标志时，会发生部分标志停止。

所以像inc 这样只设置一些标志（它没有设置CF）的指令不会固有地导致部分停顿，但会导致停顿如果 后续指令读取inc 未设置的标志（CF）（没有任何设置CF 标志的干预指令）。这也意味着写入所有有趣标志的指令永远不会涉及部分停顿，因为当它们是执行标志读取指令时最近的标志设置指令时，它们必须写入消耗的标志.

因此，一般而言，静态确定是否会发生部分标志停顿的算法是查看使用标志的每条指令（通常是 jcc 系列和 cmovcc 以及一些专门的指令，如 adc ) 然后向后走以找到设置 any 标志的第一条指令，并检查它是否设置了消费指令读取的所有标志。否则，将发生部分标志停止。

后来的架构，从 Sandy Bridge 开始，本身不会遭受部分标志stall，但仍然会受到指令添加到前端的额外 uop 形式的惩罚在某些情况下。与上面讨论的失速相比，这些规则略有不同，适用于范围更窄的案例。特别是，所谓的flag merging uop只有在一个flag消耗指令从多个flag读取并且这些flag最后被不同的指令设置时才被添加。这意味着，例如，检查单个标志的指令永远不会导致发出合并微指令。

从 Skylake 开始（可能从 Broadwell 开始），我没有发现 任何 合并 uops 的证据。相反，uop 格式已扩展到最多 3 个输入，这意味着单独重命名的进位标志和一起重命名的 SPAZO 组标志都可以用作大多数指令的输入。例外情况包括像 cmovbe 这样的指令，它有两个寄存器输入，其条件 be 需要使用 both C 标志和一个或多个 SPAZO 标志。然而，大多数条件移动只使用 C 和 SPAZO 标志中的一个或另一个，并且采用一个 uop。

示例

这里有一些例子。我们讨论了“[partial flag]stalls”和“merge uops”，但如上所述，两者中最多只有一个适用于任何给定的架构，所以像“以下导致停止并发出合并 uop”之类的内容应该被解读为“以下导致停顿 [在那些具有部分标志停顿的旧架构上] 或合并 uop [在那些使用合并 uops 的新架构上]”。

停止和合并uop

以下示例将导致在 Sandy Bridge 和 Ivy Bridge 上发出停顿和合并 uop，但不会在 Skylake 上发出：

add rbx, 5   ; sets CF, ZF, others
inc rax      ; sets ZF, but not CF
ja  label    ; reads CF and ZF

ja 指令分别读取 CF 和 ZF 分别由 add 和 inc 指令设置，因此插入合并 uop 以统一单独设置的标志以供 @987654341 使用@。在停顿的架构上，发生停顿是因为ja 从CF 读取，而该CF 不是由最近的标志设置指令设置的。

仅摊位

add rbx, 5   ; sets CF, ZF, others
inc rax      ; sets ZF, but not CF
jc  label    ; reads CF

这会导致停顿，因为在前面的示例中，CF 被读取，它不是由最后一个标志设置指令设置的（这里是inc）。在这种情况下，可以通过简单地交换inc 和add 的顺序来避免停顿，因为它们是独立的，然后jc 将只从最近的标志设置操作中读取。不需要合并 uop，因为读取的标志（仅 CF）都来自相同的 add 指令。

注意：此案例正在辩论中（请参阅 comments） - 但我无法对其进行测试，因为我在我的 Skylake 上根本找不到任何合并操作的证据。

没有停顿或合并uop

add rbx, 5   ; sets CF, ZF, others
inc rax      ; sets ZF, but not CF
jnz  label   ; reads ZF

这里不需要停顿或合并 uop，即使最后一条指令 (inc) 只设置了一些标志，因为消费 jnz 只读取由inc 设置的标志（一个子集）并且没有其他。因此，这种常见的循环习语（通常使用dec 而不是inc）本身不会导致问题。

这是另一个不会导致任何停顿或合并 uop 的示例：

inc rax      ; sets ZF, but not CF
add rbx, 5   ; sets CF, ZF, others
ja  label    ; reads CF and ZF

这里ja 确实读取了CF 和ZF，并且存在一个inc，它没有设置ZF（即，部分标志写入指令），但没有问题，因为add 位于 inc 之后并写入所有相关标志。

班次

移位指令sar、shr 和shl 在其可变计数和固定计数形式中的行为与上述不同（通常更差），并且这在不同架构之间变化很大。这可能是由于它们奇怪且不一致的标志处理¹。例如，在许多架构上，当在计数不是 1 的移位指令之后读取 any 标志时，会出现部分标志停止的情况。即使在最新的架构上，变量移位的成本也很高，为 3由于标志处理而导致的 uops（但不再有“停顿”）。

我不会在此处包含所有血腥细节，但如果您想了解所有细节，我建议您在 Agner 的microarch doc 中查找 shift 这个词。

一些旋转指令在某些情况下也有有趣的标志相关行为，类似于移位。

---

¹ 例如，根据移位计数是 0、1 还是其他值来设置不同的标志子集。