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

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

p0上的分支单元只能运行预测未采取的JCC uops（或宏融合的JCC uops），但这些是常见的。p6上的分支单元是处理采取分支的“主要”单元。

对于直接分支（jmp rel8/rel32/调用rel32），可以在解码和重新引导获取阶段检查预测，可能会使前端停顿，但我认为永远不需要在后端触发任何类型的恢复。对于直接无条件分支，永远不会发出来自错误路径的Uops。管道重新引导有perf计数器。

分支错误预测使用分支顺序缓冲区可以快速恢复，这与异常时通常回滚到停用状态不同（当发生中断时，管道中的指令会发生什么？）。有关管道如何在停用之前将所有内容视为推测性的更多信息，请参阅乱序执行与推测性执行。

根据大卫·坎特的桑德布里奇微建筑文章：

Nehalem增强了从分支错误预测中的恢复，这种错误预测已经延续到Sandy Bridge中。一旦发现分支错误预测，核心能够在知道正确路径后立即重新开始解码，同时乱序机器正在从错误推测的路径中清除uops。以前，在管道完全刷新之前，解码不会恢复。

（Skylake的BOB有48个条目，所以48个尚未执行的分支正在运行中。我认为BOB条目应该在执行分支uop时被释放，而不需要一直分配到退休。）

这是由分支顺序缓冲区实现的“快速恢复”，该缓冲区根据条件和间接分支指令快照reg重命名状态，即使在正常程序中也会错误预测。但是异常和内存排序机器清除成本更高。它们确实会发生（尤其是页面错误），但是它们更少，更难优化。

快速恢复的关键点是，在ROBRS（调度程序）中已经被错误预测的分支之前的uops可以继续执行，而后面的uops被丢弃，前端重新引导到正确的地址。因此，如果JCC uop的输入足够早地准备好，如果CPU在恢复时可以咀嚼很长的依赖链，大部分分支未命中的惩罚可以被隐藏。例如，退出带有相当长的循环的循环时的错误预测，或者除了总uop吞吐量或端口6瓶颈之外的任何瓶颈。请参阅通过计算条件提前避免停滞管道

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

相关内容：描述分支错误预测惩罚是一篇关于分支未命中和长缓存未命中如何与ROB交互的有趣论文。它基于一个简化的管道模型，但在我看来，它的发现可能适用于Skylake。