Skip to content

Use P.INSTR_CLASS_PRED in bpred - #1967

Open
davidharrishmc wants to merge 1 commit into
openhwfoundation:mainfrom
davidharrishmc:dh/bpred-instr-class-pred
Open

davidharrishmc wants to merge 1 commit into
openhwfoundation:mainfrom
davidharrishmc:dh/bpred-instr-class-pred

Conversation

@davidharrishmc

Copy link
Copy Markdown
Contributor

bpred.sv hard-coded `define INSTR_CLASS_PRED 1 and never read P.INSTR_CLASS_PRED, which was added to cvw_t, the configs, and 22 bpred_*_0_rv32gc derivatives in January 2024 but never wired up. As a result every _0 derivative built identically to its _1 twin, and BTB/RAS sweeps since May 2023 (the old +define+INSTR_CLASS_PRED=0 was also overridden by the in-file `define) measured class prediction on.

Default configs set 1, so they are unchanged. With 0, icpred decodes call/return/jump/branch from the fetched instruction and the BTB supplies only the target.

Lint passes on all derivatives. Verilator ACT rv64gc and rv32gc pass with both settings (the only failures are the Svadu fault tests fixed by #1965), and all 22 bpred_*_0 derivatives pass. CoreMark: with 0 the class-wrong count drops to 0; cycles improve 0.3–0.4% for the default configs and 5.1% for the 64-entry-BTB GSHARE config, so published _0 vs _1 BTB/RAS comparisons should be regenerated.

🤖 Generated with Claude Code

bpred hard-coded `define INSTR_CLASS_PRED 1 and never read the config
parameter added in 32c102d, so every *_0 branch-predictor derivative
built the same as its *_1 twin. With 0, icpred decodes the instruction
class from the fetched instruction instead of predicting it in the BTB.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant