bytecodealliance / bytecodealliance/regalloc2
Modeling subregister aliasing
- Dominant language
- Rust
- Stars
- 265
- Forks
- 53
- PR merge metrics
- No merged PRs in 30d
Description
I’m experimenting with using regalloc2 for a cranelift backend targeting a old Z80 8-bit CPU with hierarchical registers —
where two small registers can form one larger register, and vice versa:
B + C = BC (16-bit)
D + E = DE (16-bit)
H + L = HL (16-bit)
Here’s the challenge:
Some 16-bit instructions can use either BC or DE.
When BC is used, both B and C become clobbered.
When DE is used, D and E are clobbered instead.
The 8-bit registers are individually addressable, but they also participate in 16-bit operations as pairs.
The problem is that regalloc2 assumes all physical registers in a class are disjoint,
and clobber sets must be fixed before allocation.
That makes it unclear how to express a relationship like “BC aliases both B and C” or “writing BC invalidates B and C.”
LLVM handles this using register units and subregisters, where overlapping registers share “register units”
and the allocator tracks partial definitions and interference on that level.
regalloc2, however, currently has no notion of aliasing or register overlap.
So I’m wondering:
Is there any way to model such subregister aliasing with the current regalloc2 API?
Would it make sense to support aliasing PRegs or register subsets (similar to LLVM’s register units / subregister indices)?
Or is the current expectation that these aliasing relationships be handled entirely outside the allocator,
e.g. by inserting explicit moves, using fixed constraints, or splitting live ranges manually?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the current regalloc2 API around PRegs, physical register classes, and clobber sets, then compare the issue's LLVM register-units and subregister model. Done means establishing whether aliasing can be represented, or documenting a supported outside-the-allocator approach such as fixed constraints, explicit moves, or live-range splitting.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100