x86 - 当 Skylake CPU 错误预测分支时究竟会发生什么？

Question

我试图详细了解当分支被错误预测时，skylake CPU 管道各个阶段的指令会发生什么变化，以及来自正确分支目标的指令开始执行的速度。

因此，让我们将这里的两个代码路径标记为红色(预测的，但未实际采用的)和绿色(采用的，但未预测的)。所以问题是:
1. 在红色指令开始被丢弃之前，分支必须通过流水线多远(以及它们在流水线的哪个阶段被丢弃)？
2. 绿色指令多久可以开始执行(就分支到达的流水线阶段而言)？

我已经查看了 Agner Fogg 的文档和大量的讲义，但没有发现这些要点。

Answer 1

分支执行单元(在端口 0 和 6 上)实际检查条件或间接分支的 FLAGS 或间接分支地址。我认为一旦执行单元发现它，恢复就开始了，而不是等到它退休。 (其中一些是我最好的猜测/理解，不一定得到英特尔优化手册的支持。)

分支预测 + 推测执行将数据依赖与控制依赖解耦，但分支 uop 本身确实对 EFLAGS 或间接地址输入有数据依赖。

p0 上的分支单元只能运行predicted-not-taken JCC uops(或macro-fused JCC uops)，但这些都是常见的。 p6 上的分支单元是处理分支的“主”单元。

对于直接分支( jmp rel8/rel32/call rel32 )，可以在解码时检查预测并重新引导获取阶段，可能会停止前端，但我认为永远不需要在后端触发任何类型的恢复。永远不会为直接无条件分支发出来自错误路径的 Uop。有用于管道重新转向的性能计数器。

分支错误预测可以通过分支顺序缓冲区快速恢复 ，与通常在异常情况下回滚到退休状态不同:When an interrupt occurs, what happens to instructions in the pipeline? .有关管道如何在退休之前将所有内容视为投机行为的更多信息，请参阅 Out-of-order execution vs. speculative execution .

根据 David Kanter's Sandybridge microarch writeup :

Nehalem enhanced the recovery from branch mispredictions, which has been carried over into Sandy Bridge. Once a branch misprediction is discovered, the core is able to restart decoding as soon as the correct path is known, at the same time that the out-of-order machine is clearing out uops from the wrongly speculated path. Previously, the decoding would not resume until the pipeline was fully flushed.

这是由分支顺序缓冲区启用的“快速恢复”，该缓冲区在条件和间接分支指令上对 reg 重命名状态进行快照，即使在正常程序中预计也会错误预测。但是异常和内存排序机器清除更昂贵。它们确实会发生(尤其是页面错误)，但它们更罕见且更难优化。

快速恢复的关键在于 已经在 ROB + RS(调度程序)中的错误预测分支之前的 uops 可以继续执行，而后面的 uops 被丢弃 并且前端重新转向正确的地址。因此，如果 JCC uop 的输入足够早地准备好，那么如果 CPU 可以在恢复时咀嚼很长的依赖链，则可以隐藏大部分分支未命中惩罚。例如从具有适当长度循环的循环退出时的错误预测带有 dep 链，或除总 uop 吞吐量或端口 6 瓶颈之外的任何瓶颈。见 Avoid stalling pipeline by calculating conditional early

如果没有快速恢复，我认为 ROB 中的所有 uops 都将被丢弃(即所有未退休的 uops)。这里可能有一些中间立场，比如在 ROB 中但已经离开调度程序的分支之前保留已经执行的 uops。我不知道 Merom/Conroe 到底做了什么。

相关: Characterizing the Branch Misprediction Penalty是一篇关于分支未命中和长缓存未命中如何与 ROB 交互的有趣论文。它基于简化的管道模型，但在我看来，它的发现可能适用于 Skylake。