Skip to content

Conversation

cjgillot
Copy link
Contributor

Follow-up to #142915

The current implementation of DestinationPropagation refuses to consider locals that are borrowed at any point in the MIR.

This PR attempts to relax this requirement without trying to perform alias analysis.

For each local, we consider they are borrowed from the first Rvalue::Ref or Rvalue::RawPtr statement until they are marked StorageDead.

The liveness analysis is modified to consider that:

  • an indirect write may write to any currently borrowed local;
  • an indirect read may read to any currently borrowed local;
  • a call/tailcall/drop/yield/inlineasm terminator may read and write to any currently borrowed local.

Future extensions may consider a move to discard borrows, but this requires work on MIR semantics beforehand.

r? @Amanieu

@rustbot
Copy link
Collaborator

rustbot commented Sep 19, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 19, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 19, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@tmiasko
Copy link
Contributor

tmiasko commented Sep 19, 2025

Those conditions are insufficient since they make it possible to observe that storage of unified locals overlaps:

$ cat a.rs 
fn main() {
    let x;
    let y;
    {
        let a = 0;
        x = &a as *const _;
        let b = a;
        y = &b as *const _;
    }
    assert!(x != y);
}
$ rustc +stage1 -O a.rs
$ ./a
thread 'main' (34419) panicked at a.rs:10:5:
assertion failed: x != y
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@Amanieu
Copy link
Member

Amanieu commented Sep 21, 2025

Right, the correct way to calculate the live range of a borrowed local is to start from the assignment that initializes it (at the late position) and end at StorageDead. This needs to be done using a separate forward dataflow analysis, but then the produced live range interval should be compatible with those from the backwards analysis for non-borrowed locals.

@cjgillot cjgillot marked this pull request as draft September 28, 2025 20:50
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 28, 2025
@bors
Copy link
Collaborator

bors commented Oct 3, 2025

☔ The latest upstream changes (presumably #142771) made this pull request unmergeable. Please resolve the merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants