Make retags an implicit part of typed copies by RalfJung · Pull Request #154341 · rust-lang/rust

RalfJung · 2026-03-24T22:06:19Z

Ever since Stacked Borrows was first implemented in Miri, that was done with Retag statements: given a place (usually a local variable), those statements find all references stored inside the place and refresh their tags to ensure the aliasing requirements are upheld. However, this is a somewhat unsatisfying approach for multiple reasons:

It leaves open the question of where to even put Retag statements. Over time, the AddRetag pass settled on one possible answer to this, but it wasn't very canonical.
For assignments of the form *ptr = expr, if the assignment involves copying a reference, we probably want to do a retag -- but if we do a Retag(*ptr) as the next instruction, it can be non-trivial to argue that this even retags the right value, so we refrained from doing retags in that case. This has come up as a potential issue for Rust making better use of LLVM "captures" annotations. (That said, there might be other ways to obtain this desired optimization.)
Normal compilation avoids generating retags, but we still generate LLVM IR with noalias. What does that even mean? How do MIR optimization passes interact with retags? These are questions we have to figure out to make better use of aliasing information, but currently we can't even really ask such questions.

I think we should resolve all that by making retags part of what happens during a typed copy (a concept and interpreter infrastructure that did not exist yet when retags were initially introduced). Under this proposal, when executing a MIR assignment statement, what conceptually happens is as follows:

We evaluate the LHS to a place.
We evaluate the RHS to a value. This does a typed load from memory if needed, raising UB if memory does not contain a valid representation of the assignment's type.
We walk that value, identify all references inside of it, and retag them. If this happens as part of passing a function argument, this is a protecting retag.
We store (a representation of) the value into the place.

However, this semantics doesn't fully work: there's a mandatory MIR pass that turns expressions like &mut ***ptr into intermediate deref's. Those must not do any retags. So far this happened because the AddRetag pass did not add retags for assignments to deref temporaries, but that information is not recorded in cross-crate MIR. Therefore I instead added a field to Rvalue::Use to indicate whether this value should be retagged or not. A non-retagging copy seems like a sufficiently canonical primitive that we should be able to express it. Dealing with the fallout from that is a large chunk of the overall diff. (I also considered adding this field to StatementKind::Assign instead, but decided against that as we only actually need it for Rvalue::Use. I am not sure if this was the right call...)

This neatly answers the question of when retags should occur, and handles cases like *ptr = expr. It avoids traversing values twice in Miri. It makes codegen's use of noalias sound wrt the actual MIR that it is working on. It also gives us a target semantics to evaluate MIR opts against. However, I did not carefully check all MIR opts -- in particular, GVN needs a thorough look under the new semantics; it currently can turn alias-correct code into alias-incorrect code. (But this PR doesn't make things any worse for normal compilation where the retag indicator is anyway ignored.)

Another side-effect of this PR is that -Zmiri-disable-validation now also disables alias checking. It'd be nicer to keep them orthogonal but I find this an acceptable price to pay.

RalfJung · 2026-03-24T22:46:18Z

@bors try
@rust-timer queue

Make retags an implicit part of typed copies

rust-bors · 2026-03-25T00:55:08Z

☀️ Try build successful (CI)
Build commit: 82d9903 (82d99031f4626ac962af0c7f6d78d1f7173d7145, parent: 362211dc29abc4e8f8cfc384740237f144929b03)

RalfJung · 2026-03-25T06:57:45Z

Looks like enabling validation of references just to keep retags working in const-eval was not a good idea...

RalfJung · 2026-03-25T07:24:27Z

@bors try
@rust-timer queue

Make retags an implicit part of typed copies

rust-bors · 2026-03-25T09:32:55Z

☀️ Try build successful (CI)
Build commit: 5bbea76 (5bbea7620d94ef1e4dd2e6617ed840cde1cf87f3, parent: 8a703520e80d87d4423c01f9d4fbc9e5f6533a02)

RalfJung · 2026-05-02T12:39:41Z

@JoJoDeveloping seems like with this PR we don't actually have to worry about read-only references in TB any more -- &mut-to-read-only gets caught before we reach that logic.

View changes since the review

…tead

rustbot · 2026-05-02T15:40:46Z

This PR was rebased onto a different main 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.

RalfJung · 2026-05-02T16:59:25Z

@bors r=oli-obk

rust-bors · 2026-05-02T16:59:29Z

📌 Commit e402c1e has been approved by oli-obk

It is now in the queue for this repository.

rust-bors · 2026-05-02T20:56:05Z

☀️ Test successful - CI
Approved by: oli-obk
Duration: 3h 13m 15s
Pushing 20de910 to main...

github-actions · 2026-05-02T20:59:29Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 3d5dfdc (parent) -> 20de910 (this PR)

Test differences

Show 188 test diffs

Stage 1

[mir-opt] tests/mir-opt/inline/inline_retag.rs: pass -> [missing] (J1)
[mir-opt] tests/mir-opt/retag.rs: pass -> [missing] (J1)

Stage 2

[mir-opt] tests/mir-opt/inline/inline_retag.rs: pass -> [missing] (J0)
[mir-opt] tests/mir-opt/retag.rs: pass -> [missing] (J0)

Additionally, 184 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 20de910db49d3476ccf49ea79a4b22e2b5dface0 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-msvc-ext1: 1h 42m -> 2h 13m (+30.1%)
dist-various-2: 34m 4s -> 43m 58s (+29.1%)
dist-x86_64-netbsd: 1h 9m -> 1h 29m (+29.1%)
x86_64-gnu-llvm-22-2: 1h 16m -> 1h 38m (+27.9%)
test-various: 2h 10m -> 1h 38m (-24.8%)
x86_64-rust-for-linux: 52m 43s -> 40m 15s (-23.7%)
armhf-gnu: 1h 29m -> 1h 11m (-20.3%)
pr-check-1: 26m 49s -> 31m 21s (+16.9%)
dist-apple-various: 1h 24m -> 1h 39m (+16.8%)
x86_64-gnu-aux: 2h 31m -> 2h 15m (-10.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-05-02T21:40:01Z

Finished benchmarking commit (20de910): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.3%, 0.6%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 5.0%, secondary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	5.0%	[5.0%, 5.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.8%	[-1.1%, -0.4%]	2
All ❌✅ (primary)	5.0%	[5.0%, 5.0%]	1

Cycles

Results (secondary 0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.2%	[0.4%, 2.4%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.7%	[-0.9%, -0.4%]	3
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.3%]	68
Regressions ❌ (secondary)	0.1%	[0.0%, 0.4%]	52
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.3%]	68

Bootstrap: 481.836s -> 482.455s (0.13%)
Artifact size: 391.13 MiB -> 391.12 MiB (-0.00%)

Make retags an implicit part of typed copies Ever since Stacked Borrows was first implemented in Miri, that was done with `Retag` statements: given a place (usually a local variable), those statements find all references stored inside the place and refresh their tags to ensure the aliasing requirements are upheld. However, this is a somewhat unsatisfying approach for multiple reasons: - It leaves open the [question](rust-lang/unsafe-code-guidelines#371) of where to even put `Retag` statements. Over time, the AddRetag pass settled on one possible answer to this, but it wasn't very canonical. - For assignments of the form `*ptr = expr`, if the assignment involves copying a reference, we probably want to do a retag -- but if we do a `Retag(*ptr)` as the next instruction, it can be non-trivial to argue that this even retags the right value, so we refrained from doing retags in that case. This has [come up](llvm/llvm-project#160913 (comment)) as a potential issue for Rust making better use of LLVM "captures" annotations. (That said, there might be [other ways](rust-lang/unsafe-code-guidelines#593 (comment)) to obtain this desired optimization.) - Normal compilation avoids generating retags, but we still generate LLVM IR with `noalias`. What does that even mean? How do MIR optimization passes interact with retags? These are questions we have to figure out to make better use of aliasing information, but currently we can't even really ask such questions. I think we should resolve all that by making retags part of what happens during a typed copy (a concept and interpreter infrastructure that did not exist yet when retags were initially introduced). Under this proposal, when executing a MIR assignment statement, what conceptually happens is as follows: - We evaluate the LHS to a place. - We evaluate the RHS to a value. This does a typed load from memory if needed, raising UB if memory does not contain a valid representation of the assignment's type. - We walk that value, identify all references inside of it, and retag them. If this happens as part of passing a function argument, this is a protecting retag. - We store (a representation of) the value into the place. However, this semantics doesn't fully work: there's a mandatory MIR pass that turns expressions like `&mut ***ptr` into intermediate deref's. Those must *not* do any retags. So far this happened because the AddRetag pass did not add retags for assignments to deref temporaries, but that information is not recorded in cross-crate MIR. Therefore I instead added a field to `Rvalue::Use` to indicate whether this value should be retagged or not. A non-retagging copy seems like a sufficiently canonical primitive that we should be able to express it. Dealing with the fallout from that is a large chunk of the overall diff. (I also considered adding this field to `StatementKind::Assign` instead, but decided against that as we only actually need it for `Rvalue::Use`. I am not sure if this was the right call...) This neatly answers the question of when retags should occur, and handles cases like `*ptr = expr`. It avoids traversing values twice in Miri. It makes codegen's use of `noalias` sound wrt the actual MIR that it is working on. It also gives us a target semantics to evaluate MIR opts against. However, I did not carefully check all MIR opts -- in particular, GVN needs a thorough look under the new semantics; it currently can turn alias-correct code into alias-incorrect code. (But this PR doesn't make things any worse for normal compilation where the retag indicator is anyway ignored.) Another side-effect of this PR is that `-Zmiri-disable-validation` now also disables alias checking. It'd be nicer to keep them orthogonal but I find this an acceptable price to pay. - [rustc benchmark results](rust-lang/rust#154341 (comment)) - [miri benchmark results](rust-lang/rust#154341 (comment))