Allocation results in unnecessary moves around destructive operations
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start with the three cases in the regalloc2-repro repository, then compare their output with the reported fib.asm and fib.vcode files from the linked botlish audit. Trace the allocation around the destructive operations and verify that the unnecessary moves into r13 are reduced without regressing the repro cases.
Written by the indexing model from the issue text.
Description
I am implementing a Cranelift-based compiler stack for a new programming language where one design objective is efficient machine code. This is why early in development I am doing audits on the generated code to find out which inefficiencies are caused by the mid-end, which by the backend and which by missing language features.
In the asm dump of my fibonacci benchmark I saw this:
177: mov rsi,r13
17a: mov r14,rax
17d: sub rsi,0x2
181: mov r13,rsi
184: shl rsi,1
187: mov r13,rsi
18a: or rsi,0x1
18e: mov r13,rsi
191: mov QWORD PTR [rbx+0x8],rsi
rsi is moved repeatedly into r13 for no discernible reason, then the content of rsi is moved into memory. r13 is later overwritten. So r13 was completely useless here.
The entire ASM is available in https://github.com/mwagner-webdev/botlish/blob/9cb689a/audit/native-scalar-asm/bench/fib.asm
This code was generated via Cranelift from this CLIF: https://github.com/mwagner-webdev/botlish/blob/9cb689a/audit/native-scalar-asm/bench/fib.vcode
I have a minimal repro here with three cases that illustrate the issue: https://github.com/mwagner-webdev/regalloc2-repro
I have zero experience with the workings of register allocators and it's all pretty fascinating. Obviously perfect allocation is impossible, but this looks like a clear-cut pathological case for which some heuristic may be found.
- 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 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 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
bytecodealliance/regalloc2#191 · 3 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