Upstreaming the RUNLTS branch predictor

[maekawatoshiki]

Hello, gem5 community!

We are considering upstreaming our implementation of the RUNLTS branch predictor into gem5.
RUNLTS is a branch predictor we proposed and that was awarded first place at the Championship Branch Prediction 2025 (CBP2025) competition.
For a detailed proposal, please refer to our CBP2025 paper and our paper in the ISCA 2026 Proceedings.

RUNLTS achieves lower MPKI than the TAGE-SC-L branch predictor across a wide variety of workloads by utilizing register values produced in the backend pipeline.
We believe adding this predictor to gem5 will contribute to a wide range of computer architecture research.

We have already published our RUNLTS implementation for the gem5 O3 CPU model at Zenodo (10.5281/zenodo.19453059).
We plan to organize and refactor this implementation for upstream, but we would like to seek community opinions regarding our implementation approach.
The main concern stems from its feature of utilizing both conventional branch history and register values produced in the backend.

1. How to propagate register values from backend to frontend

   We handle register values at the following stages:

   • decode: Set logical destination registers of decoded instructions as not yet available
   • writeback: Communicate the produced register values to the frontend, making them available for prediction/training
   • execute or commit: Train predictor tables using the saved register values

   In the current implementation, we add a reference to the branch predictor instance to the IEW class and directly pass the values during writeback.
   Since this is an ad-hoc implementation, for the upstream version we are considering extending the existing TimeBuffers to propagate register information to the frontend.
   Does this approach make sense?

2. How to calculate register digests

   RUNLTS computes a short digest from logical register numbers and their values.
   The digest calculation method used in the paper assumes AArch64 and handles integer, floating-point, and condition-code registers separately.

   For the initial implementation, we plan to provide the functionality described in the paper for AArch64, while for other ISAs, we intend to generate digests only from scalar integer registers for simplicity.
   Unsupported register classes will be excluded from both prediction and training inputs.
   Is such an implementation approach, which varies by ISAs, acceptable?

3. Creating a new implementation without inheriting from the existing TAGE_SC_L class

   While RUNLTS is based on TAGE-SC-L, it differs in some aspects, including TAGE history length sets, entry allocation policy, and statistical corrector configuration.
   Therefore, instead of inheriting from the existing TAGE_SC_L class, we plan to provide it as a standalone BPredUnit implementation.
   Is this implementation approach acceptable?

4. Providing only a 192 KiB configuration

   Since storage budget at the competition was limited to 192 KiB, we currently only have a configuration tuned for this size.
   Is there any issue with upstreaming only the 192 KiB configuration without offering multiple capacity options like TAGE_SC_L_{8,64}KB?

5. Predictor training timing

   The original competition framework trains predictor tables during branch resolution, whereas the gem5 O3 CPU trains them during commit.
   The initial upstream implementation will train predictor tables during commit to remain consistent with the existing gem5 approach.
   This may result in slightly reduced accuracy compared to our original implementation.
   Is this approach preferable?
   Additionally, are there any existing plans or discussions regarding a generic mechanism to change training timing as an option?

We hope to further discuss these points and contribute the RUNLTS implementation to gem5.

[giactra]

Hi @maekawatoshiki, many thanks for your message!
It would be nice to have your work upstreamed to gem5. I have not read your paper (yet!) and I am not able to speak for the entire community, but here's my comment:

1. How to propagate register values from backend to frontend -> Yes TimeBuffer seems like a reasonable choice. Another alternative would be via probes, but TimeBuffer has the added advantage of modelling delays. It would be nice if the interface could be as generic as possible (it's unclear to me now what that could mean) so that we don't define interfaces which only works for a single type of branch predictors. Don't consider it as a blocker, but think more like: are there other potential consumers of the regs value? Shall I define the interface to allow for such other use-cases?
2. How to calculate register digests -> We have accepted contributions tailored towards a specific ISA so I don't think this is a blocker. It's important though to document the predictor will work differently depending on the ISA...
3. Creating a new implementation without inheriting from the existing TAGE_SC_L class -> Not a problem
4. Providing only a 192 KiB configuration -> Not a problem
5. Predictor training timing -> Same as 3. You should be documenting what "slightly reduced accuracy" means in numbers so that gem5 users knows how far they would be from the original implementation in the paper...

As a summary, we would warmly welcome a PR. That would also allow other maintainers to have a better understanding of your design decisions.