Investigate better bitpacking for Operand and Use
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- rust
- Domain
- compilers, performance
Research direction
Start by locating the definitions and bit layouts for Operand and Use, then trace how their u32 fields encode register, virtual-register, instruction, and constraint information. Measure the current limits and compilation-time impact before evaluating whether infrequently used information can be stored out of line. Done should include a concrete design that raises relevant limits without expanding the common representation.
Written by the indexing model from the issue text.
Description
Two core data-structure elements, Operand and Use, are both designed to fit a relatively large amount of information in one u32. This is a performance optimization that we have found to be relatively impactful; expanding even to a u64 has a measurable impact (of at least a few percent) on compilation time.
Unfortunately, the scarcity of bits means that certain limits are lower than we would prefer. For example, we support only a 5-bit index for physical registers in each register class (so 32 integer registers and 32 float/vector registers), which may not be enough for some use-cases (though it can work for aarch64 and x64 at least). This also limits the VReg count to 1M (2^20).
We should investigate ways of, e.g., out-of-lining infrequently-used information (such as fixed-PReg constraints) to raise the limits on VRegs, PRegs, instruction count, and the like and provide enough headroom for any reasonably-imaginable use case.
- 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
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
bug rules
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
IronCoreLabs/ironcore-alloy#346 ·
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 65/100