モデルおよびBOOMv3に比べてどうも分岐予測の精度が悪い気がしているので、いろいろと調査していた。
どうしてもモデルとの比較結果が異なるので、もうちょっと考え直さないとだめだ。
- F1ステージによるuBTBによる分岐予測
- F1ステージでBTBアクセスによる分岐情報の抜き出し
- F2ステージによるGshareの分岐予測
- Gshareの分岐予測はF1ステージでのBTBの取得情報に基づく
F2ステージにおいて、GshareとuBTBの結果が異なる場合、Gshareを優先させる
Gshareの予測：
- 512-bitのキャッシュラインが存在していたとすると、512/16=32個の分岐命令が入る余地がある。これをレーンと名付ける
- 分岐命令がキャッシュラインを超えることを考慮して、RVCの場合は当該命令アドレスの最下位アドレス位置、RVC以外の場合は最下位アドレス+2を予測に使用するアドレスとする。
- BTBにより分岐と判別できなかった場合、GHRを更新しない
- 現在の
GHR ^ PC_ADDRをさらに折りたたんでGshareへのアクセス・インデックスを作成する - ジャンプすると予測する場合は
GHR << 1 | 1、ジャンプしないと予測する場合はGHR<<1 | 0とする。このGHRの値は可能な限り正しいことが好まれる。- なぜならば、この値が投機的な予測を含んでしかも復帰させない場合、値がずれる → 予測がヒットしない → 値がずれるという悪循環に陥る可能性があるから。
- したがって、分岐予測ミスが発生した場合、自分が保持している
GHRの状態からGHRをロールバックすることが好ましい。Official GHR = GHR[ :1], 実際の分岐結果
- 分岐予測ミスとは別に、全く別の要因で外部(ROB)からflushが発生したりすると、分岐命令すら無効になるときがある。この時はコミット時のGHRの状態まで復帰させることが望ましい。
- これをどのように実現する？
- br_tagの発行とともに、brtagをインデックスとしてIssue UnitにGHRを保管しておく (なるべく大回しをしたくない)
- 分岐予測ミスが発生した場合、br_tagを使用してGHRをロールバックする
- ROBからのflushが発生したときに備えて、コミット毎にGHRの安定版を保管しておき、ROB Flush時にはそれを使って復帰する。
