我刚刚过去this answer by Peter Cordes，他说，
如果标志被读取，则会发生部分标志停顿。 P4永远不会有部分标记停顿，因为它们永远不需要合并。它具有错误的依赖性。几个答案/评论混淆了术语。它们描述了一个错误的依赖，但后来称之为部分标记停顿。这是因为只写了一些标志而发生的减速，但是术语＆＃34;部分标志失速＆＃34;当部分标志写入必须合并时，预SnB Intel硬件上会发生什么。英特尔SnB系列CPU插入一个额外的uop来合并标志而不会停止。 Nehalem和早期失速约7个周期。我不确定对AMD CPU的惩罚有多大。
我不觉得我理解了一个＆＃34;部分旗帜摊位＆＃34;是。我怎么知道发生过一次？读取标志时，有时以外的事件会触发什么？合并标志意味着什么？在什么条件下＆＃34;写下的一些标志＆＃34;但部分旗帜合并并不会发生？关于国旗摊位我需要了解什么才能理解它们？
答案 0 :(得分：5)
一般来说，当标志消耗指令读取一个或多个未被最新标志设置指令写入的标志时，会发生部分标志停顿。
因此inc之类的指令只会设置一些标记（它不会设置CF）并不会 导致部分停顿，但如果后续指令读取未由CF设置的标志（inc），则会导致停止（没有任何设置CF标志的中间指令）。这也意味着写入所有有趣标志的指令从不涉及部分停顿，因为当它们是执行标志读取指令时的最新标志设置指令时，它们必须写入消耗标志
因此，一般来说，静态确定部分标志是否会停止的算法是查看使用这些标志的每条指令（通常是jcc系列和cmovcc以及一些专门的指令，如adc）然后向后走，找到设置任何标志的第一条指令，并检查它是否设置了使用指令读取的所有标志。否则，将发生部分标志停滞。
后来的架构，从Sandy Bridge开始，本身不会遇到部分标志失速，但仍会受到额外uop加入前端的惩罚。在某些情况下的指示。规则略有不同，适用于与上述摊位相比较窄的一组案例。特别是，只有当一个标志消耗指令从多个标志读取并且那些标志最后由不同指令设置时，才会添加所谓的标志合并uop 。这意味着，例如，检查单个标志的指令永远不会导致合并的uop被发出。
以下是一些例子。我们讨论＆＃34; [部分旗帜]摊位＆＃34;并且＆＃34;合并uops＆＃34;，但如上所述，这两个中只有一个适用于任何给定的体系结构，所以类似于＆＃34;以下内容会导致停顿和合并uop发出＆＃34;应该被理解为＆＃34;以下导致[在那些具有部分标记停顿的旧架构上]或合并uop [在那些使用合并uops的新架构上]＃34;。
以下示例将导致停止并合并uop：
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统一单独设置的标志以供ja消费。在停止的架构上，由于ja从CF读取而未发生最新的标志设置指令，因此会发生停顿。
注意：我们认为我们知道的事情似乎不再正确 - 请参阅the comments。上面的序列实际上并没有导致Skylake和早期架构上的合并uop。我离开了上面，因为它代表了传统智慧＆＃34;关于此事，但至少部分是错误的。
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上找不到任何合并操作的证据
add rbx, 5 ; sets CF, ZF, others
inc rax ; sets ZF, but not CF
jnz label ; reads ZF
这里没有需要的停顿或合并uop，即使最后一条指令（inc）只设置了一些标志，因为消耗jnz只读取inc设置的标志。 {1}}而没有其他人。因此，这种常见的循环习惯用法（通常使用dec代替inc）并不会导致问题。
这是另一个不会造成任何拖延或合并的例子：
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}}在其变量和固定计数表单中的行为与上述行为不同（通常更糟），这在架构之间会有相当大的变化。这可能是由于他们处理 1 的奇怪和不一致的标志。例如，在许多体系结构中，在移位指令之后读取任何标志时，有一些部分标志停止，计数不是1.即使在最近的体系结构中，变量移位的成本也很高。由于标志处理而导致的uops（但没有更多＆＃34;失速＆＃34;）。
我不会在此处包含所有血腥的详细信息，但我建议您在Agner的microarch doc中查找 shift 这个词想要所有的细节。
在某些情况下，某些旋转指令也有与标志相关的有趣行为，类似于轮班。
1 例如，根据移位计数是0,1还是其他值设置不同的标志子集。
答案 1 :(得分：1)
修改 uop 的标志可能只更新标志寄存器的一部分。 RAT 有一个用于 flags/eflags/rflags 寄存器的条目和一个掩码，显示由 uop 更改的标志，导致该条目指向的物理寄存器被分配。如果发生一系列读取和写入相同标志的指令，则为每次写入分配一个单独的物理寄存器，并且每次读取都使用前一个物理寄存器。在这些寄存器中将写入该标志，而所有其他标志将被清除。这就是为什么当从不在标志 RAT 条目中的掩码中的不同标志读取时不能使用当前物理寄存器的原因，因为它会读取一个清除位，而不是已留下的标志的真实状态。在旧的微架构上，会发生停顿，直到标志寄存器的状态在 RRF 中有效（通过等待每个标志设置 uop 退出，然后再插入它们在 RRF 标志寄存器中设置的位，其中每个 uop 被检查以了解它使用的架构寄存器/标记它更改的标志，这比 x86 宏操作更易于解释。
在使用 PRF 方案（SnB 以上）的微架构上，当没有专用的 RRF 寄存器时，需要合并 uop 来保持统一的标志寄存器，否则退休 RAT 将指向一个无意义的物理寄存器，其中只有 1 个标志 in。合并 uop 发生在每个部分标志修改指令（如 inc 或 dec）之后。 add 修改所有 6 个状态标志，因此不需要合并 uop。我认为这可能意味着状态、控制和系统标志在 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。因此，需要使用合并 uop，这也恰好比之前微架构的停顿方法更快。
合并 uop 实现
合并 uop 的一种实现可能是在每次写入部分标志 / 寄存器之前插入它，并且合并 uop 在将其全部写入新的物理寄存器之前从完整寄存器 / 标志寄存器读取。然后为写入分配相同的寄存器，这导致写入自然地合并。接下来的读取可以读取寄存器的任何部分/任何标志。这基本上在每个部分标志写入指令和之前的标志写入指令（部分或全部）之间以及每个部分寄存器写入和之前（全部/部分）写入寄存器之间建立了一个依赖链。在这种情况下，RAT 永远不会有部分重命名。
它可以在写入部分寄存器后立即分配。合并 uop 采用前一个物理寄存器（这将始终是一个完整的 rax/eax 写入，或者在标志的情况下，一个完整的状态标志更新，就像由 add 或合并 uop 完成的那样) 和新的物理寄存器，并将它们组合成新的物理寄存器。这将表明分配器插入它。如果它是由解码器插入的，则当先前的 RAT 指针未知时，分配器可以在不同的周期中分配该 uop。
它可以在从 RAT 中具有统一状态的寄存器读取之前立即分配。这意味着 RAT 将 rax/eax 分别跟踪到 ax、al 和 ah。本例中需要合并的2个物理寄存器取自RAT。
优化手册暗示它是后两种情况之一“在每次部分寄存器写入后发生合并 uop”（即写入 ax、al 或 ah、{ {3}}）。