Value Prediction 设计总结
值预测试图在生产者指令真正执行完成之前,先给出其结果值,使消费者越过真实数据依赖并提前执行。
比传统分支预测更激进:分支预测通常只猜一个控制方向,而值预测要猜完整的 8~64 位甚至更宽的数据,因此错误代价、置信度要求、验证与恢复复杂度都显著更高。
设动态指令 $I_n$ 的真实输出为 $v_n$:
- 值预测器在真实执行完成前预测 $\hat v_n = P(PC_n,\ H_n,\ C_n)$, 其中 $PC_n$ 是静态指令地址,$H_n$ 可包含分支路径、历史输出或地址历史,$C_n$ 可包含线程、特权级和其他上下文
- 若消费者已使用 $\hat v_n$,真实值到达后必须比较 $\hat v_n \stackrel{?}{=} v_n$; 不相等时需要回放依赖链、恢复重命名状态或清空部分/全部流水线
传统乱序执行只能在操作数就绪后发射消费者指令。
对于如下指令链:
1 | load r1, [r2] ; 长延迟生产者 |
即使后端还有空闲执行端口,add、cmp 和分支也由于 load 的 RAW 依赖而阻塞
值预测器若以高置信度给出 $\hat {r1}$,可以在真实 Load 尚未返回时唤醒整条依赖链。其收益不仅仅是简单减少一条 Load 指令的延迟,而是整条依赖链全部提前执行
所以值预测准确率最高的指令不一定最值得预测: 一个 99.99% 准确、但完全不在关键路径上的 Load,可能不如一个 99.9% 准确、支配多个 Cache Miss 地址或难预测分支的 feeder
准确率与覆盖率之间的平衡取决于正确预测的收益和误预测的代价。通常在 OoO Core 中,后者远大于前者,因此预测器往往更侧重准确率
值预测的收益通常来自于对关键路径的消除:如果被预测的指令并不关键,那么即便覆盖率或准确率很高,也不会带来多少性能收益
值预测技术进展
根据预测值类型,当前的值预测技术大致分为几类:
- LVP (Load Value Prediction)
- 特殊值预测
- 通用值预测
- 相等性预测
- 向量值预测
两种设计哲学:
- 追求预测高覆盖率
- 放弃覆盖率,只预测收益高的指令
值预测的预测准确率通常要求高于分支预测的准确率:
因为分支错误的恢复边界明确,而错误预测数据可能沿多个数据和内存依赖方向扩散, 恢复困难
早期的大部分工作更聚焦于提高值预测的覆盖率
预测高收益指令的代表工作:
- Intel Focused VP: 找到真正限制性能的 feeder,以小容量开销得到更高每字节收益
- Targeted VP: 预测足以把代价较高的 uop 替换成低代价操作的中间信息
值预测实现时还需要处理其他几个方向的问题
- OoO 流水线集成问题
- 多核场景的预测正确性问题
- 侧信道攻击
LVP (Load Value Prediction)
通常情况下 Load 指令对关键路径的影响相对较大(cache miss),所以当前大部分值预测工作都是基于 Load Value 的预测
LVP 本身存在不同的预测实现方式
- 直接预测 Load Value
- 预测 Store-Load Pair (Memory Renaming)
- LAP (Load Address Prediction): 先预测 Load 地址,再根据预测地址读取较新的真实值
- 证明 Load 值稳定后直接消除 Load
直接预测 Load 值
直接预测 Load 值最为常见, 大部分的值预测算法也基于直接 LVP
问题:
- 同一静态 Load PC 访问不同对象
- 中间存在冲突 Store
- 历史值虽然曾正确,却已经变旧
工业界采用直接 LVP 的有:
- Apple: A17 Pro, M3, M4 的性能核经逆向论文实测存在 LVP, 主要是按静态 Load PC 学习的常量值
Store-Load Pair Prediction/Memory Renaming
由于预测值本身不容易找到稳定值,所以预测 store-load 的关系并把 store 的值转发给 load 可以使更多的 load 提前获得值, 从而避免直接去预测一个未知的 load value
预测:$Load_j \leftarrow Store_i$
一旦 load-store 关系被高置信度识别,Load 在地址完全计算前就从 Store Queue 的候选 Store 取得当前 Store 数据
与普通 LVP 的区别是:预测器主要存 store-load pair 关系,而不是完整历史 Load 值
由于该技术类似于 register renaming , 最早提出时被称为 Memory Renaming
与 Store-To-Load-Forwarding (STLF) 不同的是:
- 普通 Store-to-Load Forwarding:Older Store 计算地址和数据, youger Load 计算地址, 检查 Store Queue 中所有 Store 的地址、大小、对齐等条件, 确认存在地址相同且可 forward 的 Store 时从 Store Queue 转发
- Memory Renaming 会直接根据 Store-Load PC 信息预测 youger load 和 older store 之间的 pair 关系,然后不等待/检查地址信息等条件,直接转发,跳过了地址检查,地址源寄存器的 bypass 等待
工业界采用 Memory Renaming 技术的有:
- AMD Zen 3 起公开的 PSF (Predictive Store Forwarding)
- AMD Zen 4 起公开的 EPSF (Extended Predictive Store Forwarding)
- Intel 官方公开的 FSFP (Fast Store Forwarding Predictor)
- Nvidia Vera CPU Core (Olympus) 声称实现了 Memory Renaming, 但未公开具体实现机制
LAP (Load Address Prediction)
- 先预测地址:$\hat a_n = P_a(PC,H)$
- 再用 $\hat a_n$ 查 L1D 或一个按地址索引、由真实内存事件维护的小值表:$\hat v_n = ValueTable[\hat a_n]$
好处: 准确率比 LVP 高,可以取到更新的值,避免静态 PC 在不同对象间切换时反复使用旧数据
缺点:load-to-use latency 比 LVP 大 (LVP: 0-cycle)
当前 LAP 方面只有 Apple M2,M3 的性能核有测试出 StrideAP(LAP) 的效果, 其余工作主要是论文:
- Qualcomm Path-based Address Prediction:先用 Load PC 和控制路径历史预测地址,再访问 DCache/内存获得值
- AVPP:Address Table 预测地址,Value Table 按地址保存经真实内存事件更新的值,并预取未来地址对应值
- SAVP 以安全投机为目标,预测 Load 地址而不是直接预测 Load Value。预测地址从 Cache 层次取得真实数据,预测验证时只保留地址比较。提出 In-flight PC Table 避免同一 Load 多个在飞实例破坏 Stride 流,Value Table + Ahead Prefetch Queue 提前提供数据,Passive Snoop Queue 监听 Store Commit 与 Cache Eviction 以保持预取值新,并在 BOOM 类开源 OOO RISC-V 核上给出 RTL/综合评估
Qualcomm Path-based Address Prediction 实验在模拟器下:
- 放宽置信度时地址预测准确率超过 99%
- 约 8 KB 结构
- 个别工作负载最高约 71%,平均约 4.8% 的 IPC 提升
AVPP 在其模拟器实验中报告 IPC 提升效果:
- 仅预测:平均约 4.8%
- 仅预取:约 1.8%
- 完整 AVPP:约 10.6%
- 完整方案覆盖率约 50.2%,准确率约 99.9%
为减轻 LAP 的 load-to-use latency 问题, Qualcomm 专利 US11243772B2 把 LAP 和 LVP 集成在一起,同时进行预测,用 LAP 的值覆盖 LVP (类似于多级分支预测的 override, LAP 的值再覆盖 LVP, 真实 Load 取值再覆盖 LAP 的值)
证明预测值稳定后直接消除 Load
Constable 是该方向最具代表性的论文:
- 动态识别地址和值长期稳定的 Load
- 跟踪形成地址的源架构寄存器是否改变
- 跟踪对目标内存位置的 Store 和一致性 Snoop
- 只要任何前提失效,就撤销稳定状态
- 在稳定期直接跳过 Load 执行并复用值
与直接预测 load value 的区别在于,该方法预测错误时 Load 本身不会导致难以恢复的状态回滚(DCache/Memory Request 不能撤回),因为该指令本身就没有被执行
论文在 90 个工作负载的模拟实验中报告:
- 单线程平均约 5.1% ipc 提升
- 动态 Core 功耗约下降 3.4%
- 2-way SMT 平均约 8.8%
- 与 EVES 叠加仍有额外收益
特殊值预测
可以针对部分特殊指令的控制字或者输出类型上进行值预测,此类控制字/结果状态一般有较多的被依赖指令,允许后续依赖指令先行,收益比预测通用值更高
- 好处: 这些特殊值的后续依赖者指令一般较多,且预测结果不是完整的 64-bit value, 预测输出准确率比预测完整的 64-bit value 高
- 缺点: 只针对部分特殊值/控制字
在工业界已有成熟应用:
- AMD 在部分处理器上会针对
FLDCW和LDMXCSR指令预测浮点控制状态, 预测值会在真实 control word 已知前供更年轻的浮点指令使用, 若真实字段与预测不同,处理器产生内部异常,清空年轻指令并以正确模式重发。 - Intel FPU 会静态预测浮点结果为 normal,从而让浮点运算及其依赖者先行执行;若真实情况是 denormal/subnormal,则触发 microcode assist
- RISCV V 扩展 vsetvl 指令输出的 vl, vtype 同样也会影响后续所有的 RVV 指令,部分 RVV 处理器会预测 vsetvl 指令的输出,便于后续 RVV 指令可以尽早发射,也相当于一种值预测
通用值预测
LVP 和特殊值预测二者更倾向于预测某一类更关键的值以尽可能提高收益,但预测类型有限,对于 load 指令依赖和特殊值指令依赖较少的情况收益有限。
通用值预测不局限于预测某一类值,只关注预测值本身的稳定性和关键性
通用值预测最早从 LVP 迁移而来:Exceeding the Dataflow Limit via Value Prediction ,该工作将 LVP 思想从 Load 指令推广到一般生产者指令,提出“superspeculation”:控制指令、地址和值都可以被预测,使执行越过传统数据流图的依赖
Intel FVP 本身也可以用于通用值预测,但该工作评估表示预测非 Load 指令的收益较低,强制将 Load 指令作为预测的硬性条件,不预测任何非 Load 指令。
Equality Prediction 相等性预测
将值预测转化为二元预测问题, 不需要存储完整的预测值,可以大幅减少存储面积, 同时提高预测准确率
Value Equality Prediction 预测当前结果是否等于某个已有值,一旦命中即可复用已有物理寄存器或转发来源;
- 优点:把预测目标从 $2^{64}$ 个可能位模式压缩为有限的等价关系
- 代价: 仍需识别候选来源并验证相等性
Storageless Value Prediction 和 Register Sharing for Equality Prediction 预测新结果是否仍等于目的寄存器里已有的值
- 优点:只需小型 confidence 状态并复用 Register File 中的旧值,避免大容量 Value Table
- 局限: 覆盖率受旧寄存器分配和编译器值保留影响
与 Move Elimination 有相似物理效果,但前者依赖动态预测,后者通常由指令语义或已知映射保证
Vector Value Prediction 向量值预测
2026 年 GLSVLSI 论文 Vector Value Prediction with Element-wise Stride Compression
将预测对象扩展到向量,以 element-wise stride compression 降低保存整条向量的成本
把标量 VP 的“值宽”问题放大为 $VL \times SEW$ 的存储与端口问题:若每个 lane 独立保存完整历史,表项会快速膨胀;元素步长/压缩表示则用规则性换取容量,但还要处理 mask、尾元素、可变向量长度和部分错误恢复
值预测算法
值预测器通常只针对单条指令预测,只有 D-VTAGE 针对 fetch block 内的所有指令进行预测(追求大覆盖率)
Last-value / Constant predictor
预测算法:$\hat v_n = v_{n-1}$
若某个静态指令长期返回同一值,Last-value 就退化为常量预测器
1996 年 ASPLOS 论文 Value Locality and Load Value Prediction 最早提出了该算法(值预测研究的起源)
该算法基于 Value locality(同一静态 Load 的动态实例经常重复相同值)
实现时需要以下硬件结构:(大多数值预测算法的标准结构)
- 训练表 LCT: 判断某个 Load 是否足够稳定, 用于训练
- 预测表 LVPT (Load Value Prediction Table): 以 Load PC 索引,保存上一次 Load 值, 用于预测
LCT 训练出高稳定 Load 指令之后进入 LVPT ,之后对于这些 Load 指令,直接预测 Value 提前驱动消费者指令
同时原本的 Load 还要继续执行取出真实的值之后验证预测值是否正确, 正确则无事发生,错误则需要预测恢复
优点: 表项简单, 训练快
缺点: 遇到相同 PC 读取不同对象、对象被写入、上下文切换或地址别名时容易产生旧预测
论文基于 PowerPC 620-like OOO 与 Alpha 21164-like in-order 模型,报告平均约 3%/6% 、个别基准更高的 IPC 提升
Example:
- Apple FLOP 逆向论文中测出的行为属于这一类:静态 Load PC 反复读取相同常量,达到较高训练阈值后,消费者可在真实 Load 前瞬态使用该值
- Huawei 专利 WO2025050307A1 描述的也是这一类预测器
Stride predictor
Stride VP 预测算法: $\Delta_n = v_n-v_{n-1},\ \hat v_{n+1}=v_n+\Delta_n$
- 适合计数器、指针按固定距离推进等
- 表项通常保存 last value、last stride 和置信度
- 若步长本身呈周期变化,可进一步用 stride history 预测下一步长
2026 年论文 Design and Implementation of Value Prediction in the EH1 Processor 在开源 EH1 处理器原型上实现了 Stride VP
IBM 专利 US6986027B2 也是类似的 stride PHT 结构
- 第一级,PC 索引 -> stride history pattern: 根据 last value + 最多四个最近/候选 stride 得到 pattern
- 第二级,Pattern History Table: 每个 pattern 对应多个小计数器来选择下一次最可能出现的 stride
- 预测结果为 $\hat v_{n+1}=v_n+\widehat{\Delta}_{n+1}$
三种特化情形:
- $\widehat{\Delta}=0$:Last-value
- 固定非零 $\Delta$:普通 Stride
- 多个 Delta 周期变化:Context/Pattern predictor
用若干较窄 stride 加一个完整 last value 可以替代保存多个完整 64 位历史值,从而降低存储
Context VP
Finite Context Method (FCM) Predictors 以一条静态指令最近 $k$ 个输出值或其 Hash 作为上下文:$Hash(v_{n-k},\ldots,v_{n-1}) \rightarrow \hat v_n$
- 可以学习交替值、短周期状态机
- 但完整历史值昂贵,且索引、标签和多端口成本高
Hybrid/Multi VP
类似于分支预测器和预取器,值预测也可以采用多种预测算法混合预测
由此也衍生出了多种预测算法并存的最终值选择问题
Selective Value Prediction 就是一种在多种预测算法的预测结果中进行选择的策略:
- 多种预测算法:Stride + Context
- Rename 时把预测值放入 PRF
- 目的寄存器记录真实/预测值和置信度
- 只有高置信度消费者可提前执行
- 并且记录预测是否被消费
- 以 benefit/loss/criticality 而非 accuracy 单指标决定是否预测
Qualcomm 2019 年 HPCA 论文: Efficient Load Value Prediction Using Multiple Predictors and Filters 组合了四类预测器 (LastVP, StrideAP, ContextVP, ContextAP),并通过 Filter 控制选择一个值预测器的预测结果:
- 哪类 Load 值得进入候选集
- 哪个子预测器负责
- 何时达到足够置信度
- 何时因历史错误停止预测
论文实验说明:
- 相对于单一/既有方案,组合和过滤使收益提高约 54%~74%
- 8 KB 配置可维持约 99% 的预测准确率
2025 年论文 Optimizing Value Prediction for ILP Processors: A Design Space Exploration Approach 重新系统比较:
- predictor 类型、表项数、Tag/值宽与关联度
- confidence counter 的阈值、更新和替换策略
- 预测覆盖、准确率、面积、能耗与 IPC 的联合 Pareto 前沿
- 面向特定 ILP 处理器宽度和窗口大小时,哪种组合才是“成本有效”,而不是只追求最高准确率
VTAGE
2014 年 HPCA 论文 Practical Data Value Speculation 提出 VTAGE:
把 TAGE 分支预测思想用于值预测:
1 | PC + history length 0 -> Base last-value |
- 只用控制流/路径历史即可在较早流水级查表
- 一个无历史 tag 的 Base/Last-value 表 + 多个带历史标签的表
- 第 $i$ 个表使用几何增长的历史长度 $L_i$,例如 2、4、8、16、32、64
- Entry 每项保存 value、partial tag、confidence、utility
- 最长历史命中项 provider 优先
- 预测错误时优先向更长历史的表分配
- Forward Probabilistic Counter 可以以牺牲覆盖率换取极高准确率
优势: 能按控制路径区分同一静态指令在不同路径下的不同值
缺点: 每项保存 64 位值非常昂贵,多 Bank 并行访问和更新端口也困难
D-VTAGE / Delta predictor
D-VTAGE 不直接保存每种绝对值,而保存相对基值的 Delta/Stride
它更适合:控制相关步长, 不同路径使用不同增量, 循环中多个迭代同时在飞 等场景
D-VTAGE 的提出者同时提出了 BeBoP: 按 Fetch Block 组织预测,每个周期可以通过单端口预测一个 fetch block 内的多个指令的值(仅适用于只有一个目的操作数的指令,对于 x86 中的复杂指令,一条指令可能输出多个目的操作数,值预测比较困难)
EVES: E-VTAGE and E-Stride
CVP1 竞赛中的 EVES 把增强 VTAGE (E-VTAGE) 和增强 Stride (E-Stride) 结合:
- 只有 E-VTAGE 置信度足够高时才使用 E-VTAGE, 否则使用 E-Stride
- E-Stride 和 E-VTAGE 覆盖的指令也几乎完全不同
- 使用 expected benefit/loss confidence 提高准确率
EgDiff
EgDiff 研究重点是:全局 Load 值相关以及深流水线中的 value-delay 问题
论文以 non-speculative update 和 deferred prediction 组织全局预测状态,避免过早用尚未确认的值污染历史;
作者报告平均准确率超过 99%、平均 IPC 提升 3.69%,并指出与 EVES 这类局部预测器组合后最高可达到约 6.12% 的 IPC 提升
流水线集成
相比于 OoO Core,In-Order Core 对于长延时指令更敏感,因此值预测在 In-Order Core 上往往能获得更高的收益
值预测的集成方式的设计哲学:
- 尽可能加快值预测指令(往往处于关键路径)的调度/执行/验证: 2025 CLUSTER 论文
- 尽量不改动 OoO 流水线,在 In-Order 部分完成值预测:EOLE
在 OoO 流水线中集成值预测
- Fetch/Decode 查表: 用 PC、分支历史、线程 ID 等索引预测器
- Rename 写入预测值: 为目的逻辑寄存器分配物理寄存器,并将预测值写入 PRF;或者生成一条内部
MOVI predicted_valueuop - Issue 标记“预测就绪”: IQ/Scheduler 可立即唤醒消费者,但 ROB/PRF 仍标记该值为 speculative
- 真实生产者指令照常执行: Load 仍访问 Store Queue、L1D 和更低层缓存;通用 ALU 仍执行原操作
- 验证: 在真实值生产者指令计算出真实数据时与预测值比较
- 恢复:若预测未被任何消费者使用,只需更新预测表;若已被消费,则选择性 replay 依赖链,或从该指令后清空流水线
- 训练和分配: 更新寄存器值、标签、置信度、utility 位及错误上下文
Fetch/Decode Stage
Fetch/Decode Stage 通常只查预测表拿到预测值,大部分的值预测算法都针对单条指令进行预测;BeBoP 为追求大覆盖率,使用 Fetch Block 的 Start PC 进行预测。
Rename Stage
Rename Stage 的集成:
- 为预测的目的逻辑寄存器分配物理寄存器,并标记为 speculative
- 写入预测值
关于预测值写入的位置有 3 种策略:(placement policy)
| Policy | 好处 | 缺点 | Example |
|---|---|---|---|
| 直接写 PRF | 最自然地融入寄存器重命名 | 会和 WB Stage 竞争 PRF 写端口,并需要在 PRF 中标记 speculative 状态 | 最常见的策略 |
| 写入 Reservation Station/Issue Queue Payload | 减少 PRF 端口压力 | 存在多个消费者的情况下 bypass 网络实现复杂 | - |
| 注入常量 uop | 不影响现有微架构,实现最简单 | 额外 uops 和 ROB/Queue 占用 | Huawei 专利 WO2025050307A1 |
直接写 PRF 的策略会导致对 PRF 写端口的竞争,一个需要考虑的问题是:值预测指令和其他指令的仲裁优先级如何决定?
2025 年的 CLUSTER 论文给出一种可行的仲裁优先级:值预测指令 > 分支指令 > 其他指令, 这是为了便于让值预测指令尽早验证,且值预测指令一般是处于关键路径的指令(其背后隐含:让处于关键路径的指令优先执行)
Issue Stage
值预测会导致更多对于 Issue Queue 的竞争,在分布式 Issue Queue 中,可以通过负载均衡来尽量减少对单个 Issue Queue 的压力
值预测指令一般面向处于关键路径中的指令,对于这些指令,2025 年的 CLUSTER 论文 通过直接将值预测指令插入 Issue Queue 的头部来优先调度这些指令,来尽可能提前值预测的调度/执行/验证
Verification/Recovery 预测错误恢复
| Policy | 好处 | 缺点 | Example |
|---|---|---|---|
| 从生产者指令后冲刷流水线 | 可以复用分支恢复机制 | 可能冲刷大量无关指令 | - |
| 选择性 replay | 只针对消费者指令选择性 replay, 保留无关指令 | 在 OoO 中实现困难,需要追踪消费者指令、二次唤醒和可能的访存撤销 | - |
| 仅在数据被消费时恢复 | 避免无效恢复 | 需要 used/consumed bit 记录 | Oracle 专利 US7788473B1、Selective VP |
选择性 replay 有两种方法实现:
- 从 IssueQueue 中选择性恢复: 依赖某次值预测的指令可能需要在 IssueQueue 中保留几十到几百个周期,从而阻止更新的指令 dispatch
- 使用专用 replay buffer: 记录依赖链便于 replay,额外的硬件投入
虽然在 OoO 中实现选择性 replay 比较困难,但在 In-Order Core 中实现比较容易。2025 年 HPCA 论文 Architecting Value Prediction around In-Order Execution 在 CVA6 的顺序流水线上实现了值预测和选择性 replay 机制。
Training 训练
同分支预测一样,值预测的训练也可以选择推测式更新或者验证后更新。
- 对于 Last VP 等侧重于提高准确率和稳定性的预测算法,更适合验证后更新,以确保预测表的稳定性
- 对于 D-VTAGE 等侧重于提高覆盖率的预测算法,更适合推测式更新,以确保值预测可以和指令窗口同步,覆盖更多指令
在 OoO 的 In-order 部分实现值预测 (EOLE)
在 OoO 中实现值预测的问题:
- 会给 IssueQueue 带来一定的压力与端口竞争
- 在执行阶段进行预测错误恢复比较困难(需要追踪所有消费者指令并选择性 replay,这样收益才比较可观)
2014 年 ISCA 论文 EOLE 提出一种在 OoO 中更适合值预测的集成方式:顺序值预测验证
EOLE 把流水线执行分为 3 个部分:
- Early in-order: Fetch to Dispatch Stages
- Out-of-order core: Issue to Writeback
- Late in-order: Commit
其核心 Insight 是一些单周期消费者指令绕过 IssueQueue:
- 结果被预测的生产者指令需要推迟到接近 Commit 时执行并验证;
- Early Execute: 源操作数已被预测的简单单周期指令 (e.g. ALU) 可在 Rename Stage Early Execute,之后这些指令可以绕过 Issue Queue
- Late Execute: 生产者指令得到真实结果之后,计算那些通过 Early Execute 的指令的真实结果, 如果预测错误就更新 (这些指令相当于不需要 replay)
好处:
- 预测错误在 in-order 后端 (commit) 统一发现并冲刷流水线,值预测本身不会影响 Issue/Execution Stage 的微架构
- 部分指令绕开 OOO 调度,后端 Issue Width 与 PRF 端口数可以收窄,抵消 VP 自身对 PRF 引入的端口成本
- 部分指令绕开 OOO 调度,在单周期指令密集的场景中等效于增大 Issue Width
缺点:
- 在 commit stage 验证并恢复流水线(经过 late execution 的指令不需要 replay),预测错误的代价比在 execution stage 验证并选择性恢复要高
- Late Execution 在 Writeback Stage 之后又引入一个 Valid/Late Exec Stage, 增加了流水线深度
多核场景下值预测: 内存一致性违例
2001 年论文 Correctly Implementing Value Prediction 指出:
- 在多线程、共享内存和一致性系统中,依赖 Load 可能观察到与最终验证点不一致的状态
- 即使生产者预测值和真实值相同,也需要检查预测窗口内的 Snoop、Invalidation 和 Read Sets
1 | Core 0 / Reader Core 1 / Writer |
只考虑第一条 Load,预测值 B 与最终真实值相同;
但依赖 Load 可能在 Writer 线程发布 head=B 之前读到旧 B->data=60, 最终 (head=B, data=60) 可能不符合所要求的内存模型
ARM 专利 US11948013B2 提出的解决方案:
- 在 Load tracking / Read-after-Read 结构中记录相关事件
- 监听 Snoop/一致性 miss
- 当一个值预测 Load 最终通过验证时,把该验证事件按类似 Acquire 的方式参与排序检查
- 即使预测 Load 自身数值正确,只要较年轻 Load 在窗口内遇到一致性风险问题,也重新处理较年轻 Load
- 尽量复用既有 Acquire、RAR 与 Snoop hazard 检查,控制面积和功耗
但理论上对于这一类 load 指令,被训练进预测表的概率并不大,因为可能会存在频繁的一致性失效
侧信道攻击
处理器可以撤销 ROB、Rename Map 和架构寄存器状态,却很难撤销已经发生的 Cache/TLB refill、替换状态、执行端口竞争、队列占用以及预测器训练;攻击者因此可以从最终没有提交的执行中恢复信息。
值预测相关侧信道攻击手段
值预测相关的侧信道大致有两类:
- 根据预测表状态, 通过时间窗口构建侧信道 (非瞬态攻击)
- 通过值预测错误的瞬态执行驱动 cache 侧信道攻击
第一类: 根据预测表状态, 通过时间窗口构建侧信道
2021 年 DAC 论文 New Predictor-Based Attacks in Processors 系统讨论基于时间窗口的侧信道对 Value Predictor 进行攻击的手段。
该工作把攻击分解为 Train、Modify、Trigger 三步,并构造 12 类攻击:这 12 类攻击通过在这 3 步中访问不同的数据的延时(正确预测、错误预测、无预测的延时不同)进行对比来确定 secret value
Train + Test 攻击: (通过 secret 相关分支,可以判断 secret 是 true/false)
要求:
- 攻击者(receiver)能够推导出受害者(sender)在 load 期间访问的值预测器索引;
- 了解源代码: receiver 可以把被访问的索引与其试图获知的 secret 是 1 或 0 关联起来
Test + Hit 攻击:
要求:receiver 能够推导出由 sender 的访问训练进值预测器状态的 secret_bit 值
- sender 至少访问秘密 confidence 次,以训练预测器。(例如,receiver 可以迫使 sender 反复执行使用 secret_bit 的代码,从而把该值训练进值预测器状态)
- receiver 在 trigger 步骤中访问一个已知数据,该访问所用的 index 与 sender 使用的 index 相同: 这次访问会触发值预测器作出与 secret_bit 相关的预测, 预测值被编码为数组索引)
- receiver 检查访问各数组元素的时间,以确定此前哪个元素被放入 cache ,从而恢复 secret_bit
Memory Dependence Predictor、Predictive Store Forwarding Predictor 虽然预测的是 Load ← Store 关系而不是完整数值,但同样保存可训练的历史状态:
- HPCA 2024 论文 Uncovering and Exploiting AMD Speculative Memory Access Predictors for Fun and Profit 在 Zen 3 上逆向 PSFP/SSBP,利用异址训练、瞬态更新和表项别名构造 Spectre-STL、Spectre-CTL 及跨进程预测器状态信道
- DAC 2023 论文 Leaky MDU 逆向 Arm Memory Disambiguation Unit,演示跨进程 Covert Channel、Kernel 信息泄漏和 Spectre 变体。
- ASPLOS 2025 论文 MDPeek 发现 Intel MDU 状态在 SGX 边界隔离不足,可恢复原本做了平衡处理的秘密相关分支,并攻击 MbedTLS RSA。
- ISCA 2026 论文 SSBench 系统测试 Intel、AMD、Arm、Apple、RISC-V 的 30 多款 CPU 与 14 类 MDP 配置,并展示新的 Intel MDP 控制、AMD 字节级控制流攻击以及不依赖传统 Cache/TLB Covert Channel 的 Apple 攻击。
第二类:通过值预测错误的瞬态执行驱动 cache 侧信道攻击
2025 年 USENIX Security 论文 FLOP
- 攻击手段:利用 LVP 攻击 M3、M4、A17 Pro 设备:Attacker 反复让某条 Load 返回值 $x$,再把真实值改成 $y$ 并延迟真实 Load;处理器会先把旧值 $x$ 转发给依赖链,等 $y$ 返回后才回滚。
- “只预测较窄的值(Apple LVP 不预测 8 字节的值)”并不足以保证安全:错误的 8/32-bit Index 或 Type Tag 可以选择一个完整的 64-bit Pointer 或 Function Entry,进而形成瞬态 Type Confusion、错误间接调用和任意地址读取。
SLAP 攻击的是相邻的 LAP:
- 错误地址可能指向程序从未访问的数据,取回的值同样会在地址验证前进入依赖链。论文在 Apple M2/M3 P-core 上观察到最高约 600-cycle 的瞬态窗口,并用 Cache 信道构造 64-bit OOB Read 与 Safari 跨站泄漏
- 说明 LAP 也存在同样的问题
预防值预测侧信道漏洞
- 禁用值预测 (ISA 需要提供 CSR/Control Word 设置)
- 软件上实现隔离
- 上下文/安全域切换时对预测状态进行 flush (需要 ISA 提供原语/或者硬件自动 flush)
- 通过 fence 指令屏蔽使用预测值的指令 (需要 ISA 提供对应的 fence 指令)
- 预测表 Tag 增加 ASID/VMID (or Hash) 实现不同进程间的预测状态隔离
- 验证前隐藏副作用 (只能规避部分场景, 存在性能损失)
- 用 PMU 检测是否可能出现侧信道攻击并通过软件提供预警(false positive 问题)
如果允许单个硬件线程只绑定某个软件线程,则不会出现预测表的共享,则无法发动侧信道攻击
直接禁用值预测
- FLOP 在 Apple M3 P-core 上实测
PSTATE.DIT=1会关闭 LVP - SLAP 实测在 Apple 上把
PSTATE.SSBS从默认 1 清为 0 可以抑制 SLAP - AMD 的
SSBD同时关闭 Speculative Store Bypass 与 PSF,PSFD只关闭 PSF;二者按 SMT Thread 控制。 - Intel 的 FSFP 控制字 只关闭 FSFP,
SSBD同时限制相关 Store Bypass;IBPB 可以作为 FSFP Training Barrier,LFENCE、权限模式变化和 Serializing Event 阻断错误转发
软件隔离
软件隔离无法修复所有微架构信道,但可以让错误值难以到达 secret:
- 浏览器用 Site Isolation 把不同站点放到不同 Address Space,避免攻击页与目标页共享 LVP/LAP 可访问的内存;同时要处理同站 Subdomain、共享 Renderer 等 Corner Case
- Heap/Type 隔离、提高对象布局随机化,以及把 WebAssembly/JavaScript Object 放入 Cage 并使用 Base-relative Offset,可以限制较窄错误值选择任意 64-bit Pointer 的能力
- 对敏感 Type Tag 使用独立 Metadata,而不是让错误浮点位模式通过 NaN-boxing 直接变成 Pointer;Intel FPVI 指南还建议使用 LFENCE、条件掩码或在语义允许时使用 FTZ/DAZ
上下文/安全域切换时 flush
- Arm FEAT_CSV2 把值预测状态纳入跨硬件上下文的预测资源隔离;硬件上下文至少包含 Exception Level、Security State、ASID、VMID 和 Translation Regime。架构只规定隔离效果,实现可以采用分区、Tag、随机化或清空
- DVP RCTX 允许软件限制指定上下文以前形成的值预测状态;它需要配合规定的 DSB 与 Context Synchronization,可能很慢,主要面向 ASID/VMID 变化等特殊场景
- Arm 专利 US11861368B2 在 Execution State Switch 后暂时禁止使用旧 Prediction Table,其要求明确包含 Value Prediction
- SiFive 专利 US11429392B2 在安全域切换时进入限制模式,逐步重置包括 Value Predictor、Memory-dependence Predictor 在内的表项;未清理部分禁止预测,并用固定 Reset Interval 避免清表时间本身泄漏旧状态。
- Intel 专利 US11675594B2 的 PFENCE 丢弃或替换 Predictor Context
- AMD-PSF 规定预测状态按 CPL/ASID/PCID/CR3/SMM Context 隔离并在相关切换时清理
Fence 屏蔽值预测指令
- Arm CSDB 原语要求屏障后的非分支指令不能使用屏障前尚未解析的数据值预测、部分 NZCV/SVE Predicate 预测结果执行
- Arm SB 更强地阻止屏障后指令因控制流或数据值推测产生侧信道可观察效果。
- Intel 专利提出 RFENCE 指令要求等待影响指定 Register 的 Control/Data Speculation 解析后,才允许消费者指令使用该寄存器
好处:不 flush 预测表,允许无关控制流推测
预测表 Index/Tag 增加 ASID/VMID
Ventana 专利 US11803638B2 把 ASID、VMID、Privilege Mode 等 Translation Context 加入 Store-dependence Predictor 的 Index/Tag,只有上下文匹配时才允许预测转发
好处:不同进程间隔离预测状态,各自仍可使用原本的训练状态, 不影响值预测的效果
缺点: Tag Array 存储开销, 不同进程间存在容量竞争
在验证前隐藏副作用
如果仍希望让预测值依赖链提前计算,就必须让其副作用在验证前不可观察
问题:损失一定的性能, 目前的实现只能预防部分侧信道攻击,依然存在其他侧信道攻击的可能
STT 把 Value Prediction 看作一种 Implicit Branch:
- 未验证预测值和由它取得的数据被标为 Tainted;
- 依赖 Secret/Tainted Operand 的 Transmit Instruction 延迟执行;
- Predictor 只由 Untainted Data 更新;
- 若误预测恢复时机本身依赖 Secret,也延迟 Squash/Recovery,避免恢复延迟成为信道
Speculative Value Prediction(SVP) 在 STT 框架中:
- 在 Rename 阶段,根据依赖关系将消费者 load 指令的源操作数(值预测得到)标记为污点 Tainted
- 在 Dispatch 阶段,带有污点操作数的 load 被发送至值预测器。如果值预测器能够给出高置信度结果,这条不安全 load 就会被转换为 VP-Ld,并可安全地提前执行
- 只有 VP-Ld 的操作数解除污点 Tainted 状态时才可以对 Cache 发起请求从而进行验证,否则不允许发起真实访寸请求进行验证
SafeSpec、InvisiSpec 一类 Shadow Cache/Speculative Buffer 方案也可以扩展为把 Value-predicted 依赖链的 Cache/TLB 更新推迟到验证后,但原论文没有实现 Value Predictor 的隔离
Speculative Interference Attacks 进一步证明,只隐藏直接 Cache 更新仍可能被资源竞争绕过:错误路径可以改变较老、最终提交指令的时序,并间接留下 Cache 差异。因此还需要限制预测值依赖指令对端口、MSHR、ROB/IQ、Memory Queue 等共享资源的干扰
工业界 CPU 值预测支持
| Vendor | Arch | 机制判断 | 来源 |
|---|---|---|---|
| Apple | A17 Pro、M3、M4 性能核 | Last-Value VP; Stride VP; LAP | FLOP、SLAP |
| AMD | Zen 1 | 特殊值预测:x87 FCW 的 PC/RC 与 MXCSR 的 RC/FTZ/DAZ | AMD Speculation、AMD 17h OSRR |
| AMD | Zen 3~5 | Memory Renaming: PSF/EPSF | AMD-PSF |
| Intel | 官方称某代处理器有采用 | Memory Renaming: FSFP | Intel FSFP |
| Intel | 未知 | 特殊值预测:FPU 静态预测结果为 normal | Intel Speculation、Intel FPVI |
| NVIDIA | Vera CPU / Olympus core | 官方把 value prediction 列为 dependency-breaking capability;VP 模块位于 Rename/Allocation Mid Core;具体预测对象和算法未公开 |
Vera 白皮书 |
Apple
Apple Silicon CPU Optimization Guide 未披露 LVP 的表结构或提供普通应用可用的显式调优接口。
SLAP 论文逆向测试:先预测 Load 地址,再取得预测地址的数据
2025 IEEE S&P 论文 SLAP 证明,Apple 的数据依赖投机并非从完整 LVP 才开始。
论文首先在 M2/M3 性能核上构造串行 RAW Load 链:当同一静态 Load 的有效地址形成固定步长时,硬件会在真实地址链尚未完成前访问预测地址;即使内存中的返回值被随机化,只要地址仍按步长变化,加速仍然存在,从而把机制识别为 Load Address Predictor(LAP)
与 Prefetch 的区别:
- Prefetch 只把预测 cacheline 取入 Cache,不能把数据当作寄存器结果唤醒 RAW 消费者指令
- LAP 按预测地址发起瞬态 Load,预测地址对应的数据能够进入后续依赖计算
- 计算出真实地址后仍需验证;错误地址已造成的 Cache/TLB 副作用可能形成侧信道漏洞
| 属性 | SLAP 实测 |
|---|---|
| 可靠激活训练 | 地址步长链通常需要约 500 次或更多迭代;M2/M3 的阈值并不相同 |
| 可观察步长范围 | 论文测试中绝对步长约不超过 255 字节 |
| 瞬态窗口 | 特定微基准最高约 600 周期 |
| 预测 Key | 同一静态 Load PC 的地址历史/步长行为 |
| 数据来源 | 预测地址对应的当前 Cache/内存层次数据,而非历史返回值表 |
FLOP 论文逆向测试
USENIX Security 2025 论文 FLOP: Breaking the Apple M3 CPU via False Load Output Predictions 使用定制 benchmark 和瞬态执行侧信道,确认:
- A17 Pro、M3、M4 的性能核: 存在 Load Value Prediction
- A15、A16、M2: 未观察到
- 对应能效核: 未观察到同类行为
测试结果如下:
| 属性 | 实测观察 |
|---|---|
| 预测算法 | 稳定常量;未观察到一般 Stride 值序列 |
| 静态 Load 容量 | 可同时维持约 72 个 Load PC 的训练状态 |
| 训练次数 | 约 250 次重复 Load 后进入可预测状态 |
| 可影响的瞬态窗口 | 最高约 330 个周期 |
| 1/2/4 字节 Load | 可预测任意测试常量 |
| 8 字节 Load | 测试中仅稳定观察到零值预测 |
| 状态寿命 | 在没有强烈容量冲突时可维持较久 |
| DIT | 论文在 M3 上观察到 Data Independent Timing 状态可抑制该行为 |
专利:StrideAP + LVP
Apple 专利 US11829763B2:描述了与 SLAP 逆向结果高度相关的 StrideAP:
- Fetch/Decode 附近用 Load 标识访问预测表
- 训练表保存真实地址或
base + stride关系及置信度,达到阈值后再分配到预测表 - 若预测地址落入 Store Queue/STLF 场景,可降低置信度、取消 Cache 路径并改走 Store Queue
- 依据预测路径相对正常路径节省多少周期决定是否继续训练,避免预测一个几乎没有净收益的 Load
- 允许把安全上下文信息加入预测 Key 或 Tag (地址预测状态本身也需要域隔离)
Apple 专利 US12067398B1 则将 LAP 和 LVP 结合起来, 二者共享同一个训练表(预测表独立)
用共享训练状态筛掉大量不稳定 Load,只把完整值存储和高带宽预测端口留给少数强候选 Load
- LVP table、LAP table 独立
- 训练表共享: 所有候选 Load 先在小表中记录值 Hash、置信度、连续错误数、分配方向等,避免一开始就为每个候选保存完整 64 位值
- 训练达到阈值后进入精确 LVP 表,稳定地址进入地址预测表
- 训练表只存 Hash 时,硬件仍需一次真实执行取得完整值再分配
- 同一 Load 同时符合地址和值预测时,可优先 LVP
- 预测值可直接写入 PRF 或 Issue Queue/Scheduler
- 错误时 replay 或 flush,并降低置信度/回收表项
专利 :可能的 VTAGE
专利 US12159142B1 描述:
- VTAGE LVP 与非 VTAGE LVP 可能并行访问, 命中时优先使用 VTAGE provider
- 通过 Tagged Bank 区分同一 Load PC 在不同控制路径下返回不同值
- 对表访问进行仲裁,以解决多 Bank、多 Load 和有限读端口的冲突
AMD:部分 FP 状态预测与 PSF/EPSF
FCW/MXCSR 值预测: 预测浮点部分控制字
AMD 2019 年官方白皮书 Speculation Behavior in AMD Micro-Architectures 说明,为加速浮点代码,部分 AMD 处理器会在以下指令上预测控制状态:
FLDCW:预测 x87 Floating-Point Control Word 的 Precision Control(PC)与 Rounding Control(RC)LDMXCSR:预测 MXCSR 的 Rounding Control(RC)、Flush To Zero(FTZ)与 Denormals Are Zero(DAZ)
预测值会在真实 control word 已知前供更年轻的浮点指令使用, 若真实字段与预测不同,处理器产生内部异常,清空年轻指令并以正确模式重发。对该投机敏感的软件可在 FLDCW 或 LDMXCSR 后放置 LFENCE 限制后续投机执行
Family 17h Models 00h–2Fh OSRR 给出具体的 PMU 信息:
PMCx005[3] X87CtrlRet:由 RC/PC 误预测或 mask 位变化导致的 x87 control-word mispredict trapPMCx005[1] SseCtrlRet:由 RC/FTZ/DAZ 误预测或 mask 位变化导致的 SSE control-word mispredict trap
PSF (Predictive Store Forwarding)
AMD PSF 白皮书 描述的 Predictive Store Forwarding 会学习某个 Store/Load 指令对过去是否经常发生 STLF在地址尚未完全解析时,预测器先选择候选 Store,并把该 Store 当前数据交给 Load 消费者
1 | Store PC ----\ |
预测错时,错误 Load 及其消费者被清空/重执行
AMD 官方称:
- 从 Zen 3 开始支持 PSF
- 从 Zen 4 开始加入 Extended Predictive Store Forwarding(EPSF): 扩大可预测场景,可能在某一 Store/Load 对尚未发生传统转发的情况下尝试预测;因此覆盖更高、错误概率也更大
- 白皮书描述: 以 CPL、ASID、PCID、CR3、SMM 等上下文限制预测状态,并在部分域切换时刷新
PSF/EPSF 可以通过寄存器开关:
MSR 48h bit 2:SSBD,可连同相关 speculative store bypass 行为一起关闭MSR 48h bit 7:PSFD,只关闭 PSFCPUID Fn8000_0008 EBX[28]:PSFD 支持指示- 控制可按 SMT 线程设置
Intel
Fast Store Forwarding Predictor
Intel 官方安全文档称,某些 Intel 处理器支持 Fast Store Forwarding Predictor(FSFP)
其目标与 AMD PSF 类似:在所有转发条件解析完成前,预测一个较老 Store 会向较年轻 Load 提供数据
静态预测浮点结果类型
Intel Hardware Features and Behaviors Related to Speculative Execution 明确写道,FPU 会静态预测浮点结果为 normal,从而让浮点运算及其依赖者先行执行;若真实情况是 denormal/subnormal,则触发 microcode assist
Intel FPVI 进一步说明:
- 某些浮点操作在特定输入上需要 assist 才能产生正确结果
- assist 触发前,依赖操作可能使用一个与最终正确结果不同的瞬态结果
- assist 到达后,处理器清空流水线并重启,以得到正确架构结果
- 瞬态结果若进入地址计算或间接分支,可形成 Floating Point Value Injection
该技术属于数据结果类别预测/fast-path speculation
ISCA 2020 论文: Focused Value Prediction
Intel 研究人员提出 Focused Value Prediction,反对给尽可能多的指令做值预测:
- PMU/运行时逻辑识别 delinquent load 或难预测分支
- 沿数据依赖反向走一小段 backslice
- 找到距离瓶颈较近、但自身结果更可预测的 feeder
- 只为这些 feeder 分配值预测表
- 预测值在 Scheduler/PRF 中标为 ready
- 真实结果在 Writeback 验证,错误则重启流水线并降低置信度
识别关键指令:
- retirement stall heuristic: 把会阻塞 OOO 处理器退休的指令定义为关键指令
- 对造成停顿的指令本身做值预测并不能消除 retire 瓶颈,因为值预测不会改变该指令的实际执行。相反,如果预测产生该停顿指令源操作数的那些指令,就能更早发射停顿指令,并可能消除瓶颈。
- 可能有其他指令依赖于这个关键指令,它们也可能在未来阻塞退休。因此,对关键路径根本身进行值预测也可能有益
- Critical Instruction Table: (32 项、直接映射, 每个 entry 保存: 11 bit Tag + 2 bit confidence + 2 bit utility)指令执行时,检查指令与 ROB 退休指针(ROB 中最老表项)的距离。若该距离小于机器的提交宽度,这条指令可能阻塞退休,并很可能是某条潜在关键路径的根,因此记录到 CIT。(每次触发,置信度和效用值都加 1,直至饱和。置信度饱和后,该指令被认定为关键根,并成为 FVP 的加速目标)
与该论文对应的一个公开专利 US10846093B2 给出了一种实现框架:
- predictor 更靠近 Register File
- 通过 backslice detector 动态寻找 feeder
- Prediction Table Entry 包含 IP、Value 和约 4 位置信度
- 高置信度时将源操作数标记 ready
- Writeback Stage 比较真实值
论文实验结果表明:
- 约 1.2 KB FVP 在 Skylake-like 机器下 IPC 平均约 3.3% 提升
- IPC 提升面向未来的扩展机器约 8.6%
- 同预算传统追求大覆盖率的方案约 1.7% / 4.7%
- 即使给传统方案更多存储或覆盖,也难以显著超过“高影响密度”的选择策略
设计哲学
Intel VP 设计呈现出三个方向:
- 关系预测: FSFP,用当前 Store 数据打断内存依赖
- 类别预测: 浮点结果通常为 normal,选择常见快速路径
- 完整值预测: FVP 只把昂贵的完整值阵列用于关键 feeder
NVIDIA:Vera/Olympus
NVIDIA 官方 Olympus 白皮书把 Core 划分为 Front End、Rename/Allocation Mid Core、Scheduling and Execution Engine、Load/Store 与 Cache Subsystem
其中 memory renaming、value prediction、critical-path acceleration 被统称为 dependency-breaking capabilities;目标是减少 pointer-heavy code、serialized memory operations 和 long dependency chains 的停顿。但未说明其 Value Prediction 的具体技术细节(而且没有相关论文/专利)
因此可以猜测 Olympus 中的 Value Prediction 大概率也是类似 LAP/LVP 之类的预测方式
ARM
ARM 也没有 Value Prediction 相关技术细节说明,但其 ISA 中存在控制 Value Prediction 影响的相关指令: Prediction Restriction 指令族包括 CFP RCTX、DVP RCTX、CPP RCTX
其中,DVP = Data Value Prediction Restriction, 规定软件可建立的值预测上下文边界
ARM 还规定值预测训练不得使用因转换/权限故障而 load 的数据,并提供 CSDB、SB 等限制推测数据使用的机制
ISA 手册说明 Prediction Restriction 指令:
- Armv8.0-A~Armv8.4-A 可选
- Armv8.5-A 及以后必选
- 目的在于阻止先前执行上下文收集的预测信息影响后续推测执行
专利 US11948013B2 侧重于处理值预测在多核场景下的可能导致的内存一致性违例问题
Qualcomm
(LAP) MICRO 2017 论文:Path-based Address Prediction: 先用 Load PC 和控制路径历史预测地址,再访问 Cache/当前内存层次获得值
(MultiVP) HPCA 2019 论文: Efficient Load Value Prediction Using Multiple Predictors and Filters 组合四类预测器 (LastVP, StrideAP, ContextVP, ContextAP),并通过 Filter 控制选择一个值预测器的预测结果
专利 US11243772B2 把 LAP 和 LVP 集成在一起,同时进行,用 LAP 的值覆盖 LVP (类似于多级分支预测,LVP 0 load-to-use cycle, LAP 的值再覆盖 LVP, 真实 Load 取值再覆盖 LAP 的值)
Huawei
专利 WO2025050307A1 是 LVP 相关专利
- 采用 Last-Value Prediction 预测表索引: Load PC + Branch History Register (区分同一 Load 在不同控制路径下的值)
- 用 Prediction Throttling Table 记录:Load PC 在哪些 branch context 曾导致错误预测和 pipeline squash, 后续预测禁止该 Load
- 预测值不写入 PRF, 而是打包成
MOVIuop 进入 OoO 流水线
硬件结构:
- TT(Training Table): 观察较多 Load,只保存折叠值 Hash、短期重复置信度、线程 ID 等状态
- VT(Value Table): 只保存提升后的高稳定候选,含完整值、Tag、上下文、效用位
- VT 的预测门槛可比 TT 的候选门槛高约一个数量级以上,体现极保守输出
- UVT / per-uop state: 为 in-flight uop 保存预测值和上下文,以便验证、训练和恢复
- Bank Board: 在有限 VT 读端口间仲裁多个候选 Load
- Prediction Throttling Table: 记录 Load PC 在哪些 branch context 曾导致错误预测和 pipeline squash, 后续相同上下文暂时被禁止预测,Entry 随时间老化
预测表索引本身包含 Branch History Register, 因此不同路径的 Load 本身就在不同的 Entry, 这和降低预测表对应 Entry 置信度有什么区别?
IBM
专利 US6986027B2 使用 stride PHT 结构
Oracle
相关专利:
- US7788473B1: 预测错误时使用 used bit 标记只在预测值被使用时才 replay 流水线
- US7856548B1: PC+分支历史 LVP、动态置信度阈值、收益/损失自适应