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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants