GVN: consider constants of primitive types as deterministic by cjgillot · Pull Request #149366 · rust-lang/rust

cjgillot · 2025-11-26T23:54:59Z

GVN separates MIR constants into deterministic and non-deterministic constants. Deterministic constants are defined here as: gives the exact same value each time it is evaluated.

This was mainly useful because of ConstValue::Slice that generated an extra AllocId each time it appeared in the MIR. That variant has been removed. This is still useful for valtrees that hold references, which generate a fresh AllocId for each evaluation.

This PR proposes to consider all constants of primitive type to be deterministic. If a constant of primitive type passes validation, then it does not contain provenance, so we have no risk of having a reference becoming different AllocIds. In particular, valtrees only are leaves.

r? @ghost for perf

cjgillot · 2025-11-26T23:55:12Z

@bors try @rust-timer queue

Gvn primitive

rust-bors · 2025-11-27T02:12:54Z

☀️ Try build successful (CI)
Build commit: 576a61d (576a61d19539ab75e0e4d0799b5c43a37f899cca, parent: 1be6b13be73dc12e98e51b403add4c41a0b77759)

rust-timer · 2025-11-27T03:32:08Z

Finished benchmarking commit (576a61d): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +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.6%	[0.3%, 1.0%]	3
Regressions ❌ (secondary)	0.2%	[0.1%, 0.2%]	3
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.2%]	15
Improvements ✅ (secondary)	-0.2%	[-0.3%, -0.1%]	2
All ❌✅ (primary)	-0.1%	[-0.5%, 1.0%]	18

Max RSS (memory usage)

Results (primary 0.4%)

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

	mean	range	count
Regressions ❌ (primary)	4.4%	[3.8%, 5.0%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.3%	[-3.7%, -0.9%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-3.7%, 5.0%]	5

Cycles

Results (secondary 2.9%)

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)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%, secondary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.5%]	11
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	51
Improvements ✅ (primary)	-0.2%	[-0.5%, -0.1%]	18
Improvements ✅ (secondary)	-0.3%	[-0.6%, -0.1%]	11
All ❌✅ (primary)	-0.0%	[-0.5%, 0.5%]	29

Bootstrap: 468.01s -> 469.007s (0.21%)
Artifact size: 386.86 MiB -> 386.97 MiB (0.03%)

RalfJung · 2025-12-03T07:44:20Z

This PR proposes to consider all constants of primitive type to be deterministic. If a constant of primitive type passes validation, then it does not contain provenance, so we have no risk of having an AllocId becoming different pointers.

What is your notion of "primitive type"? For me that includes references and raw pointers and function pointers, but apparently that is not included in your definition?

EDIT: Ah, ty.is_primitive()... yeah I've been confused by that in the past.^^

RalfJung · 2025-12-03T07:46:38Z

compiler/rustc_middle/src/mir/consts.rs

-                | ConstValue::Indirect { .. },
-                _,
-            ) => true,
+            Const::Val(..) => true,


Why is this true? It can contain provenance after all, so it can be affected by #128775.

I realize that my PR description and the comments around this function do not reflect how it is used. I'll rephrase everything as a "we can duplicate the const inside a given MIR body".

cjgillot · 2025-12-18T22:19:27Z

@RalfJung I reworded the PR description and the comments to make the two separate concepts ("const can be cloned" and "const can be created") more explicit. I'd like to hear your suggestions.

RalfJung · 2025-12-20T14:11:18Z

The PR description doesn't make either of these concepts explicit I think? The comment in the file helps a lot, thanks.

This was mainly useful because of ConstValue::Slice that generated an extra AllocId each time it appeared in the MIR. That variant has been removed. This is still useful for valtrees that hold references, which generate a fresh AllocId for each evaluation.

It still exists, but it is not non-deterministic any more.

RalfJung · 2025-12-20T13:58:12Z

compiler/rustc_mir_transform/src/gvn.rs

+//! different runtime values each time they are evaluated. This used to be the case with
+//! `ConstValue::Slice` which have a new pointer each time they are evaluated, and is still the
+//! case with valtrees that generate a new allocation each time they are used. This is checked by
+//! `is_deterministic`.


I see no reason to keep a comment for a case that does not exist any more. What is a case that is still relevant today?

RalfJung · 2025-12-20T13:59:07Z

compiler/rustc_mir_transform/src/gvn.rs

+//! Conversely, some constants cannot cross crate boundaries, which could happen because of
+//! inlining. For instance, constants that contain a fn pointer (`AllocId` pointing to a
+//! `GlobalAlloc::Function`) point to a different symbol in each codegen unit. To avoid this,


"codegen unit" is a smaller boundary than "crate boundary" -- this means they have to stay in the same function, not just in the same crate, right?

RalfJung · 2025-12-20T14:01:54Z

compiler/rustc_mir_transform/src/gvn.rs

@@ -1767,7 +1809,16 @@ fn op_to_prop_const<'tcx>(
    // Check that we do not leak a pointer.
    // Those pointers may lose part of their identity in codegen.
    // FIXME: remove this hack once https://github.com/rust-lang/rust/issues/79738 is fixed.


#79738 is fixed. But #128775 is still open so maybe we still need this hack?

RalfJung · 2025-12-20T14:03:32Z

compiler/rustc_mir_transform/src/gvn.rs

@@ -1809,10 +1874,9 @@ impl<'tcx> VnState<'_, '_, 'tcx> {
        // Check that we do not leak a pointer.
        // Those pointers may lose part of their identity in codegen.
        // FIXME: remove this hack once https://github.com/rust-lang/rust/issues/79738 is fixed.


Another reference to the same closed issue

RalfJung · 2025-12-20T14:07:00Z

compiler/rustc_mir_transform/src/gvn.rs

+//! inlining. For instance, constants that contain a fn pointer (`AllocId` pointing to a
+//! `GlobalAlloc::Function`) point to a different symbol in each codegen unit. To avoid this,
+//! when writing constants in MIR, we do not write `Const`s that contain `AllocId`s. This is
+//! checked by `may_have_provenance`.


may_have_provenance is only used in an assertion, so -- that can't really be the place where this is checked, right? It's only the sanity check.

RalfJung · 2025-12-20T14:10:35Z

compiler/rustc_mir_transform/src/gvn.rs

 //!
-//! Second, when writing constants in MIR, we do not write `Const::Slice` or `Const`
-//! that contain `AllocId`s.
+//! Conversely, some constants cannot cross crate boundaries, which could happen because of


Suggested change

//! Conversely, some constants cannot cross crate boundaries, which could happen because of

//! Conversely, some constants change their value when moved across crate boundaries, which could happen because of

It'd probably also be good to reference #128775 here

bors · 2025-12-22T03:14:58Z

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

rustbot · 2026-01-11T15:46:26Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Elaborate comments. Co-authored-by: Ralf Jung <[email protected]>

rustbot · 2026-02-22T20:03:09Z

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.

cjgillot · 2026-02-22T20:03:16Z

@bors r=RalfJung

rust-bors · 2026-02-22T20:03:19Z

📌 Commit a2c3ebf has been approved by RalfJung

It is now in the queue for this repository.

@ghost

GVN: consider constants of primitive types as deterministic *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149366)* GVN separates MIR constants into deterministic and non-deterministic constants. Deterministic constants are defined here as: gives the exact same value each time it is evaluated. This was mainly useful because of `ConstValue::Slice` that generated an extra `AllocId` each time it appeared in the MIR. That variant has been removed. This is still useful for valtrees that hold references, which generate a fresh `AllocId` for each evaluation. This PR proposes to consider all constants of primitive type to be deterministic. If a constant of primitive type passes validation, then it does not contain provenance, so we have no risk of having a reference becoming different `AllocId`s. In particular, valtrees only are leaves. r? @ghost for perf

Zalathar · 2026-02-23T02:30:22Z

CI note: The x86_64-gnu-aux job stopped updating its logs hours ago, which suggests that it's on a cursed slow/stalled runner and probably won't finish.

jhpratt · 2026-02-23T02:38:55Z

That job has been problematic recently. The queue isn't very long (only 3 including this, assuming the rollup succeeds), so let's just move on.

@bors yield

rust-bors · 2026-02-23T02:38:59Z

Auto build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/22286721320

The next pull request likely to be tested is #153000.

rust-bors · 2026-02-23T09:59:11Z

☀️ Test successful - CI
Approved by: RalfJung
Duration: 3h 39m 26s
Pushing eeb94be to main...

github-actions · 2026-02-23T10:02:07Z

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 d3e8bd9 (parent) -> eeb94be (this PR)

Test differences

Show 6 test diffs

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

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard eeb94be79adc9df7a09ad0b2421f16e60e6d932c --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

dist-x86_64-apple: 2h 2m -> 2h 35m (+27.6%)
dist-apple-various: 2h 15m -> 1h 41m (-25.1%)
dist-aarch64-linux: 2h 29m -> 1h 52m (-24.8%)
dist-aarch64-msvc: 2h 1m -> 1h 41m (-16.0%)
x86_64-mingw-2: 2h 24m -> 2h 42m (+12.0%)
dist-aarch64-llvm-mingw: 1h 35m -> 1h 25m (-11.0%)
i686-gnu-nopt-1: 2h 28m -> 2h 12m (-11.0%)
tidy: 2m 40s -> 2m 57s (+10.5%)
i686-gnu-1: 2h 29m -> 2h 14m (-9.9%)
x86_64-msvc-1: 2h 28m -> 2h 42m (+9.8%)

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-02-23T10:41:09Z

Finished benchmarking commit (eeb94be): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.7%	[0.6%, 0.8%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.3%	[-0.7%, -0.2%]	15
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	1
All ❌✅ (primary)	-0.1%	[-0.7%, 0.8%]	18

Max RSS (memory usage)

Results (primary -0.4%, secondary 2.0%)

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

	mean	range	count
Regressions ❌ (primary)	2.2%	[0.6%, 3.2%]	4
Regressions ❌ (secondary)	2.9%	[2.6%, 3.3%]	3
Improvements ✅ (primary)	-3.9%	[-5.8%, -2.1%]	3
Improvements ✅ (secondary)	-0.7%	[-0.7%, -0.7%]	1
All ❌✅ (primary)	-0.4%	[-5.8%, 3.2%]	7

Cycles

Results (secondary -0.3%)

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)	4.6%	[4.6%, 4.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-3.0%, -2.6%]	2
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.3%	[0.0%, 1.6%]	7
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	15
Improvements ✅ (primary)	-0.2%	[-0.5%, -0.1%]	19
Improvements ✅ (secondary)	-0.3%	[-0.6%, -0.1%]	8
All ❌✅ (primary)	-0.1%	[-0.5%, 1.6%]	26

Bootstrap: 480.206s -> 481.498s (0.27%)
Artifact size: 397.91 MiB -> 395.88 MiB (-0.51%)

Mark-Simulacrum · 2026-02-24T03:23:25Z

Some nice wins on a number of benchmarks. The regressions look potentially real but are generally outweighed by the improvements.

@rustbot label +perf-regression-triaged

rustbot added 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. labels Nov 26, 2025

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Nov 26, 2025

Auto merge of #149366 - cjgillot:gvn-primitive, r=<try>

576a61d

Gvn primitive

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 26, 2025

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Nov 27, 2025

cjgillot changed the title ~~Gvn primitive~~ GVN: consider constants of primitive types as deterministic Nov 27, 2025

RalfJung reviewed Dec 3, 2025

View reviewed changes

cjgillot force-pushed the gvn-primitive branch from 5840636 to 1d83adb Compare December 16, 2025 01:39

This comment has been minimized.

Sign in to view

cjgillot force-pushed the gvn-primitive branch from f3daca6 to c8e1653 Compare December 17, 2025 01:02

RalfJung reviewed Dec 20, 2025

View reviewed changes

cjgillot force-pushed the gvn-primitive branch 2 times, most recently from e0e7199 to 04cb159 Compare January 11, 2026 15:41

cjgillot assigned RalfJung Jan 11, 2026

cjgillot marked this pull request as ready for review January 11, 2026 15:46

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 11, 2026

cjgillot and others added 6 commits February 22, 2026 19:43

Try harder to evaluate constants.

8c90786

Constants of primitive types are always deterministic.

4953a8b

Bless incremental.

a182053

Move methods to gvn.rs.

38c6851

Elaborate comments. Co-authored-by: Ralf Jung <[email protected]>

Use may_have_provenance.

e83ccae

Rebase fallout.

a2c3ebf

cjgillot force-pushed the gvn-primitive branch from b0986e9 to a2c3ebf Compare February 22, 2026 20:03

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 22, 2026

This comment has been minimized.

Sign in to view

Zalathar mentioned this pull request Feb 23, 2026

Rollup of 5 pull requests #152992

Closed

This comment has been minimized.

Sign in to view

rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 23, 2026

rust-bors bot merged commit eeb94be into rust-lang:main Feb 23, 2026
12 checks passed

rustbot added this to the 1.95.0 milestone Feb 23, 2026

rust-bors bot mentioned this pull request Feb 23, 2026

Add a layout_of_val intrinsic for when you want both size_of_val+align_of_val #152867

Open

cjgillot deleted the gvn-primitive branch February 23, 2026 23:35

rustbot added the perf-regression-triaged The performance regression has been triaged. label Feb 24, 2026

	//! Conversely, some constants cannot cross crate boundaries, which could happen because of
	//! Conversely, some constants change their value when moved across crate boundaries, which could happen because of

Uh oh!

Comments

Conversation

cjgillot commented Nov 26, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cjgillot commented Nov 26, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Nov 27, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Nov 27, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

RalfJung commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

cjgillot commented Dec 18, 2025

Uh oh!

RalfJung commented Dec 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Dec 22, 2025

Uh oh!

rustbot commented Jan 11, 2026

Uh oh!

rustbot commented Feb 22, 2026

Uh oh!

cjgillot commented Feb 22, 2026

Uh oh!

rust-bors bot commented Feb 22, 2026

Uh oh!

This comment has been minimized.

Zalathar commented Feb 23, 2026

Uh oh!

jhpratt commented Feb 23, 2026

Uh oh!

rust-bors bot commented Feb 23, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Feb 23, 2026

Uh oh!

Uh oh!

github-actions bot commented Feb 23, 2026

Test differences

Job duration changes

Uh oh!

rust-timer commented Feb 23, 2026

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

Mark-Simulacrum commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

cjgillot commented Nov 26, 2025 •

edited by rustbot

Loading

RalfJung commented Dec 3, 2025 •

edited

Loading

RalfJung Dec 3, 2025 •

edited

Loading