Allow emitting more enums as SSA values
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
In https://github.com/rust-lang/rust/pull/138157/files#diff-ec1143edac0931158bf79d598432eb162f53400086d30bfe1ba5266559831174R17 you can see that, because it's in a loop (I think [ed: wrongly, apparently]), the Option<u32> ends up getting spilled to an alloca despite it having ScalarPair ABI.
However it's only used in the same basic block, with the use after the initialization. Thus ideally we'd be able to just emit it as SSA values directly, rather than needing the read/write to the alloca.
(The full rule is probably a dominance check, but I don't know if the full one is worth doing, vs a simple approximation that catches common cases.)
Contributor guide
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.
Research direction
Start with the compiler change shown in PR 138157 and reproduce the linked Godbolt example involving Option. Trace where the enum is written to and read from an alloca, then determine the safe scope for emitting SSA values directly. Done means eligible same-block enum uses avoid the alloca without changing behavior, while cases requiring broader control-flow handling remain correct.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100