CPU Study - Tournament Predictor and Update the Predictor

参考来源：《超标量处理器设计》—— 姚永斌

之前提到的基于历史的分支预测总结如下：

基于局部历史的分支预测
与前后分支指令相关性不大，自身具有规律性的指令预测方法。

基于全局历史的分支预测
与上下文中的分支指令强相关的预测方法。

竞争的分支预测

竞争的分支预测法就是根据不同分支指令的执行情况自动选择不同的分支预测方案。

CPHT (Choice Predict History Table) 由分支指令的PC值进行HASH后寻址得到的两位计饱和数器信息表格（也可以采用PC和GHR异或的结果）。
如果当前的分支预测方法两次都预测失败了，就会切换状态机使用另外一个分支预测方法。

分支预测的信息更新

对于分支预测的信息，需要更新的内容包括：

历史寄存器

对于基于局部历史的预测而言，因为BHR存储的是当前分支的历史记录，所以一般在指令退休阶段进行更新，在确定指令正确与否之后更新不会降低太多性能。
对于基于全局历史的预测而言，取指，执行（方向已经被计算，是否正确还无法确认），提交（指令退休，正确与否可以确认）三个阶段可以更新GHR。

提交（Commit）阶段更新GHR

虽然此时指令结果是确定的，但是在流水线深度较深场景下，会导致预测结束提交时，很多后面的预测指令可能都无法享受到当前指令的预测结果。例如：
一条分支指令b，在时间T被分支预测，时间T + Δt从流水线中退休并更新GHR，任何在Δt时间段内被预测的分支指令都不会从分支指令b的预测结果受益。
尤其是当分支指令b前面存在D-Cache miss的load指令时，还会使分支指令b达到退休阶段所需要的时间延长。

执行（Execute）阶段更新GHR

对于非超标量处理器而言，由于执行阶段与取指阶段间隔并不会很久，所以执行时更新GHR不会对后续的分支指令使用GHR进行预测产生影响。
但是对于超标量处理器而言，不仅执行和取指阶段之间的指令数量多，而且因为乱序执行的原因，执行阶段的分支指令可能处于分支预测失败的错误路径之中，此时更新GHR未必准确。

取指（Fetch）阶段更新GHR

在取指阶段更新GHR，即使后续分支预测都使用了错误的GHR也不影响这些指令从流水线上被抹除。
但是这种方式需要在预测失败时对GHR进行修复：

(1) 提交（Commit）阶段修复
每次当一条分支指令退休时，就会更新到Retired GHR中。
前端取指Fetch使用的是Speculative GHR，用于进行分支预测。
后端提交Commit使用的是Retired GHR用于存储退休的分支指令，因此GHR肯定正确。
当前端分支预测失败时，就可以从后端的GHR写入前端的GHR中，完成修复。
缺点是会造成分支预测失败时的惩罚增大，尤其是D-Cache miss的load指令。

(2) Checkpoint 修复
在取指阶段对前端Speculative GHR更新的同时可以将旧的GHR保存，这个保存内容就是Checkpoint GHR。
如果这条分支指令结果在流水线中被计算出来是正确的，就继续执行。
如果计算出来是错误的，就恢复为Checkpoint GHR上的内容，并从这条分支指令正确的目标地址开始取指令执行。
可以算是在乱序执行场景下对GHR提交阶段修复的一种方法补充，加快分支指令在预测失败时的修复。

两位饱和计数器

不管是全局还是局部历史的分支预测，都需要通过PHT饱和计数器捕捉规律，因此PHT也需要更新饱和计数器。
当一条分支指令比较有规律时，对应的饱和计数器应该处于饱和状态。
因此即使在退休阶段再更新PHT的饱和计数器，也不会对预测准确度产生太大的负面影响。所以基本都在退休阶段更新。