前回の続き：

UFTQとUDPのポイント

上のジレンマ(timeliness↔汚染、しかもoff-pathは一概に捨てられない)を崩すために、UDP論文は2つの解決方法を提案している。

UDP: off-pathでも“有用な候補だけ”を学習して出す

UFTQが「どれだけ先読みするか(FTQ深さ)」を調整するのに対し、UDPは prefetch candidate(候補)単位で“出す/捨てる”を学習して、特に off-pathでのunuseful(汚染)を削る。

基本方針はシンプルで、

on-path：最終的に「正しかった」制御フロー(正解経路)上でフェッチ/実行される命令・フェッチブロック

off-path：分岐予測が外れた結果として一時的にフェッチされる「間違った」制御フロー(誤予測経路)上の命令・フェッチブロック

UDPは、分岐予測器(TAGE)の confidence (High/Medium/Low) を使い、confidence counter を更新して off-path を推定する。
- Low: +2、Medium: +1、High: +0
- counterが閾値を超えるとoff-path扱いに切り替える
branch recovery と BTB resteer のたびに counter をリセットする。
さらに例外として、taken予測した分岐PCがBTB miss の場合も off-path扱いにする。

off-pathモードでは、各prefetch candidateについて useful-set membership をチェックし、set内に存在し、かつ命令キャッシュに無い場合にだけprefetchを発行する。
useful-setの学習は「off-pathで出したprefetchが、後でon-pathで本当に役に立った」場合だけに限定する：
- on-path demandがoff-path prefetchにヒットしたときだけ useful-set に挿入する。
- off-pathで消費されただけのものを学習すると“off-path専用の無駄”を学習してしまうため、それは学習に使わないと明記している。
このuseful-setは実際にはハードウェアとしてはBloomFilterとして実装されるとなっている。

UDPは Seniority-FTQ を追加し、FTQから消えた off-path prefetch candidate block を保持する。
backendがretireする命令の line address を照合し、候補に一致したら「このoff-path prefetchはuseful」と判定して useful-set を更新する。
flush時はflush pointまでのブロックをSenior-FTQから削除する。
これはROB相当の巨大な追跡ではなく、fetch block単位・candidateを含むブロックだけなので小さくできる、と説明している。

useful-setはmembershipテストができれば良いので Bloom filter で実装する。
連続するラインがまとめて有用になる傾向を使い、挿入前に super-line(2本/4本連続など)へ圧縮する：
- 直近8個の候補をバッファし、連続アドレスを検出してまとめる
- 1/2/4本の3種類に対応するBloom filterを用意し、lookup結果に応じて1/2/4本分のprefetchを発行
- Bloom filterサイズ例：1-block=16k bits、2-block=1k bits、4-block=1k bits
Bloom filterの具体：
- false positive率は 1%、hash関数は 6個UDP_Utility-Driven_Fetch_Direct…
- hashは並列計算、banked SRAMからbitを読んで全ビット1ならmembership成立(レイテンシ1〜6 cycles)
フィルタ運用：Bloom filterが満杯になり、unuseful ratioが0.75に達したらクリアする。

off-path推定用：TAGE confidenceの入力、confidence counter、閾値判定、リセット制御(branch recovery / BTB resteer)
学習用：Seniority-FTQ(off-path candidate block保持＋retire時照合＋flush時削除)
useful-set保持：Bloom filter(3本：1/2/4-block)＋super-line生成バッファ
付随カウンタ：unuseful ratio追跡(0.75でクリア)