Support for cold blocks
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by locating blockparams_out and the block-ordering and register-allocation entry points that determine bundle merging and split points. Trace how cold blocks could be marked and ordered after normal blocks, then evaluate the impact on RPO-dependent heuristics; done means spills and moves prefer cold blocks without breaking allocation.
Written by the indexing model from the issue text.
Description
It would be useful to be able to mark some blocks as "cold" which means that they are rarely taken cold paths. The register allocator should prefer placing spills and moves in cold blocks if possible.
It turns out that very little needs to be done if we take advantage of the block ordering by requiring all cold blocks to be after normal blocks in terms of block index and instruction indices. This has the following consequences:
- Due to the sorting of
blockparams_out, bundle merging will attempt to merge all branch parameters coming from normal blocks before attempting to merge ones coming from cold blocks. - If a requirement conflict exists within a bundle, the bundle is split at the first conflict point. Since ranges are iterated in order, this will place the split in a cold block if there are no conflicts within normal blocks.
- If register allocation requires splitting a bundle, the first conflict point is used as the split point. Same as above.
My only concern is that the block order will no longer be in RPO which is the ordering recommended by the documentation. While regalloc2 will still function properly, I am less sure of the impact it may have on the heuristics.
Note that there are no requirements related to the ordering of blocks, and there is no requirement that the control flow be reducible. Some heuristics used by the allocator will perform better if the code is reducible and ordered in reverse postorder (RPO), however: in particular, (1) this interacts better with the contiguous-range-of-instruction-indices live range representation that we use, and (2) the "approximate loop depth" metric will actually be exact if both these conditions are met.
- Dominant language
- Rust
- Stars
- 266
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bytecodealliance/regalloc2
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
bytecodealliance/regalloc2#265 · 7 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
bytecodealliance/regalloc2#247 · 3 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
bytecodealliance/regalloc2#222 · 4 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
bytecodealliance/regalloc2#206 · 2 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
bytecodealliance/regalloc2#194 · 7 comments ·
All issues in bytecodealliance/regalloc2
Similar issues
-
todo:perf
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Openstate:needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zed-industries/zed#64611 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
objectionary/phie#154 ·