GVN: Support unions. #146355

cjgillot · 2025-09-09T01:27:03Z

Supporting union values is not very hard, and allows to const-prop them.

r? @ghost for perf

cjgillot · 2025-09-09T01:27:20Z

GVN: Support unions.

rust-bors · 2025-09-09T03:49:13Z

☀️ Try build successful (CI)
Build commit: 366a987 (366a9875a4c25a2e49bf4797159bb426a8ffd701, parent: 9c27f27ea3bab79a2fec827ef3ae0009959d60f4)

rust-timer · 2025-09-09T08:15:45Z

Finished benchmarking commit (366a987): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

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.

@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
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.9%, secondary 2.5%)

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

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	3.6%	[0.7%, 5.2%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.8%]	2
All ❌✅ (primary)	2.9%	[2.9%, 2.9%]	1

Cycles

Results (secondary 2.8%)

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.8%	[2.4%, 3.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 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.1%, 0.2%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.2%, 0.2%]	6

Bootstrap: 467.433s -> 467.12s (-0.07%)
Artifact size: 387.54 MiB -> 387.87 MiB (0.08%)

rustbot · 2025-09-14T21:40:08Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

cjgillot · 2025-09-19T00:15:13Z

r? compiler

jackh726 · 2025-09-26T04:32:53Z

@bors r+

bors · 2025-09-26T04:32:56Z

📌 Commit 6fba73e has been approved by jackh726

It is now in the queue for this repository.

GVN: Support unions. Supporting union values is not very hard, and allows to const-prop them. r? `@ghost` for perf

bors · 2025-09-26T11:00:16Z

⌛ Testing commit 6fba73e with merge df8b765...

bors · 2025-09-26T11:34:49Z

💔 Test failed - checks-actions

cjgillot · 2025-10-06T14:14:49Z

@bors r=jackh726

bors · 2025-10-06T14:14:52Z

📌 Commit 8c1dfbb has been approved by jackh726

It is now in the queue for this repository.

rustbot · 2025-10-06T19:32:47Z

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.

cjgillot · 2025-10-06T19:33:19Z

Rebase after #144477
@bors r=jackh726

bors · 2025-10-06T19:33:23Z

📌 Commit 96c3978 has been approved by jackh726

It is now in the queue for this repository.

bors · 2025-10-07T00:22:43Z

⌛ Testing commit 96c3978 with merge ff5be13...

bors · 2025-10-07T03:30:20Z

☀️ Test successful - checks-actions
Approved by: jackh726
Pushing ff5be13 to master...

github-actions · 2025-10-07T03:33:05Z

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 68ad253 (parent) -> ff5be13 (this PR)

Test differences

Show 6 test diffs

Stage 1

[mir-opt] tests/mir-opt/const_prop/union.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/dest-prop/union.rs: pass -> [missing] (J0)

Stage 2

[mir-opt] tests/mir-opt/const_prop/union.rs: [missing] -> pass (J1)
[mir-opt] tests/mir-opt/dest-prop/union.rs: pass -> [missing] (J1)

Additionally, 2 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 ff5be13e2d9f398c38215958021e4c7970f88914 --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-rust-for-linux: 2464.4s -> 3106.3s (26.0%)
dist-apple-various: 3450.2s -> 4119.6s (19.4%)
tidy: 214.5s -> 190.5s (-11.2%)
dist-aarch64-apple: 8034.2s -> 7225.1s (-10.1%)
armhf-gnu: 5165.4s -> 4700.4s (-9.0%)
i686-msvc-2: 7228.1s -> 7875.4s (9.0%)
dist-powerpc64le-linux-gnu: 5238.5s -> 5702.6s (8.9%)
aarch64-gnu-llvm-20-1: 3906.9s -> 3606.2s (-7.7%)
dist-various-1: 3665.3s -> 3935.4s (7.4%)
aarch64-msvc-2: 5104.5s -> 4738.0s (-7.2%)

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 · 2025-10-07T04:42:24Z

Finished benchmarking commit (ff5be13): 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.1%	[0.1%, 0.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -2.4%, 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)	2.3%	[2.1%, 2.6%]	3
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.4%]	1
Improvements ✅ (secondary)	-2.2%	[-3.3%, -0.6%]	4
All ❌✅ (primary)	-2.4%	[-2.4%, -2.4%]	1

Cycles

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

Binary size

Results (primary 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.2%, 0.3%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.0%, 0.3%]	5

Bootstrap: 473.761s -> 473.87s (0.02%)
Artifact size: 388.37 MiB -> 388.40 MiB (0.01%)

RalfJung · 2025-10-09T09:09:36Z

What exactly does this assume about unions? I see something involving an "active field" and my alarm bells go off; unions in Rust do not have a notion of active field, they are basically just syntactic sugar for transmutes.

cjgillot · 2025-10-09T11:44:38Z

The two simplifications we perform are:

constant folding, which may introduce constants with undef bytes, more often than transmutes;
Union { x: foo }.x simplified to foo.

We do no assume any behaviour if the projection field is not the construction field.

For the "active" terminology, I saw it inside rustc, so I thought it ok.

RalfJung · 2025-10-09T13:14:38Z

Okay, that sounds good, thanks.

scottmcm · 2025-10-10T18:36:54Z

compiler/rustc_mir_transform/src/gvn.rs

+    /// A union aggregate value.
+    Union(FieldIdx, VnIndex),


cc @saethlin -- I wonder if you can use this to solve your uninit-array problem now that GVN tracks unions?

Yes. Working on it.

Fix MaybeUninit codegen using GVN This is an alternative to #142837, based on #146355 (comment). The general approach I took here is to aggressively propagate anything that is entirely uninitialized. GVN generally takes the approach of only synthesizing small types, but we need to generate large consts to fix the codegen issue. I also added a special case to MIR dumps for this where now an entirely uninit const is printed as `const <uninit>`, because otherwise we end up with extremely verbose dumps of the new consts. After GVN though, we still end up with a lot of MIR that looks like this: ``` StorageLive(_1); _1 = const <uninit>; _2 = &raw mut _1; ``` Which will break tests/codegen-llvm/maybeuninit-rvo.rs with the naive lowering. I think the ideal fix here is to somehow omit these `_1 = const <uninit>` assignments that come directly after a StorageLive, but I'm not sure how to do that. For now at least, ignoring such assignments (even if they don't come right after a StorageLive) in codegen seems to work. Note that since GVN is based on synthesizing a `ConstValue` which has a defined layout, this scenario still gets deoptimized by LLVM. ```rust #![feature(rustc_attrs)] #![crate_type = "lib"] use std::mem::MaybeUninit; #[unsafe(no_mangle)] pub fn oof() -> [[MaybeUninit<u8>; 8]; 8] { #[rustc_no_mir_inline] pub fn inner<T: Copy>() -> [[MaybeUninit<T>; 8]; 8] { [[MaybeUninit::uninit(); 8]; 8] } inner() } ``` This case can be handled correctly if enough inlining has happened, or it could be handled by post-mono GVN. Synthesizing `UnevaluatedConst` or some other special kind of const seems dubious.

…cottmcm Fix MaybeUninit codegen using GVN This is an alternative to rust-lang#142837, based on rust-lang#146355 (comment). The general approach I took here is to aggressively propagate anything that is entirely uninitialized. GVN generally takes the approach of only synthesizing small types, but we need to generate large consts to fix the codegen issue. I also added a special case to MIR dumps for this where now an entirely uninit const is printed as `const <uninit>`, because otherwise we end up with extremely verbose dumps of the new consts. After GVN though, we still end up with a lot of MIR that looks like this: ``` StorageLive(_1); _1 = const <uninit>; _2 = &raw mut _1; ``` Which will break tests/codegen-llvm/maybeuninit-rvo.rs with the naive lowering. I think the ideal fix here is to somehow omit these `_1 = const <uninit>` assignments that come directly after a StorageLive, but I'm not sure how to do that. For now at least, ignoring such assignments (even if they don't come right after a StorageLive) in codegen seems to work. Note that since GVN is based on synthesizing a `ConstValue` which has a defined layout, this scenario still gets deoptimized by LLVM. ```rust #![feature(rustc_attrs)] #![crate_type = "lib"] use std::mem::MaybeUninit; #[unsafe(no_mangle)] pub fn oof() -> [[MaybeUninit<u8>; 8]; 8] { #[rustc_no_mir_inline] pub fn inner<T: Copy>() -> [[MaybeUninit<T>; 8]; 8] { [[MaybeUninit::uninit(); 8]; 8] } inner() } ``` This case can be handled correctly if enough inlining has happened, or it could be handled by post-mono GVN. Synthesizing `UnevaluatedConst` or some other special kind of const seems dubious.

Fix MaybeUninit codegen using GVN This is an alternative to #142837, based on #146355 (comment). The general approach I took here is to aggressively propagate anything that is entirely uninitialized. GVN generally takes the approach of only synthesizing small types, but we need to generate large consts to fix the codegen issue. I also added a special case to MIR dumps for this where now an entirely uninit const is printed as `const <uninit>`, because otherwise we end up with extremely verbose dumps of the new consts. After GVN though, we still end up with a lot of MIR that looks like this: ``` StorageLive(_1); _1 = const <uninit>; _2 = &raw mut _1; ``` Which will break tests/codegen-llvm/maybeuninit-rvo.rs with the naive lowering. I think the ideal fix here is to somehow omit these `_1 = const <uninit>` assignments that come directly after a StorageLive, but I'm not sure how to do that. For now at least, ignoring such assignments (even if they don't come right after a StorageLive) in codegen seems to work. Note that since GVN is based on synthesizing a `ConstValue` which has a defined layout, this scenario still gets deoptimized by LLVM. ```rust #![feature(rustc_attrs)] #![crate_type = "lib"] use std::mem::MaybeUninit; #[unsafe(no_mangle)] pub fn oof() -> [[MaybeUninit<u8>; 8]; 8] { #[rustc_no_mir_inline] pub fn inner<T: Copy>() -> [[MaybeUninit<T>; 8]; 8] { [[MaybeUninit::uninit(); 8]; 8] } inner() } ``` This case can be handled correctly if enough inlining has happened, or it could be handled by post-mono GVN. Synthesizing `UnevaluatedConst` or some other special kind of const seems dubious.

Fix MaybeUninit codegen using GVN This is an alternative to rust-lang/rust#142837, based on rust-lang/rust#146355 (comment). The general approach I took here is to aggressively propagate anything that is entirely uninitialized. GVN generally takes the approach of only synthesizing small types, but we need to generate large consts to fix the codegen issue. I also added a special case to MIR dumps for this where now an entirely uninit const is printed as `const <uninit>`, because otherwise we end up with extremely verbose dumps of the new consts. After GVN though, we still end up with a lot of MIR that looks like this: ``` StorageLive(_1); _1 = const <uninit>; _2 = &raw mut _1; ``` Which will break tests/codegen-llvm/maybeuninit-rvo.rs with the naive lowering. I think the ideal fix here is to somehow omit these `_1 = const <uninit>` assignments that come directly after a StorageLive, but I'm not sure how to do that. For now at least, ignoring such assignments (even if they don't come right after a StorageLive) in codegen seems to work. Note that since GVN is based on synthesizing a `ConstValue` which has a defined layout, this scenario still gets deoptimized by LLVM. ```rust #![feature(rustc_attrs)] #![crate_type = "lib"] use std::mem::MaybeUninit; #[unsafe(no_mangle)] pub fn oof() -> [[MaybeUninit<u8>; 8]; 8] { #[rustc_no_mir_inline] pub fn inner<T: Copy>() -> [[MaybeUninit<T>; 8]; 8] { [[MaybeUninit::uninit(); 8]; 8] } inner() } ``` This case can be handled correctly if enough inlining has happened, or it could be handled by post-mono GVN. Synthesizing `UnevaluatedConst` or some other special kind of const seems dubious.

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 Sep 9, 2025

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Sep 9, 2025

Auto merge of #146355 - cjgillot:gvn-union, r=<try>

366a987

GVN: Support unions.

This comment has been minimized.

Sign in to view

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

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Sep 9, 2025

cjgillot force-pushed the gvn-union branch from de25069 to 6fba73e Compare September 14, 2025 21:38

cjgillot marked this pull request as ready for review September 14, 2025 21:40

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 14, 2025

cjgillot added A-mir-opt Area: MIR optimizations A-mir-opt-GVN Area: MIR opt Global Value Numbering (GVN) labels Sep 14, 2025

rustbot assigned jackh726 Sep 19, 2025

jackh726 approved these changes Sep 26, 2025

View reviewed changes

bors 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-review Status: Awaiting review from the assignee but also interested parties. labels Sep 26, 2025

bors added a commit that referenced this pull request Sep 26, 2025

Auto merge of #146355 - cjgillot:gvn-union, r=jackh726

df8b765

GVN: Support unions. Supporting union values is not very hard, and allows to const-prop them. r? `@ghost` for perf

This comment has been minimized.

Sign in to view

bors removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Sep 26, 2025

This comment has been minimized.

Sign in to view

bors 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 Oct 6, 2025

cjgillot added 2 commits October 6, 2025 19:31

GVN: Support unions.

5407eb8

Repurpose defunct test.

96c3978

cjgillot force-pushed the gvn-union branch from 8c1dfbb to 96c3978 Compare October 6, 2025 19:32

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 7, 2025

bors merged commit ff5be13 into rust-lang:master Oct 7, 2025
11 checks passed

rustbot added this to the 1.92.0 milestone Oct 7, 2025

bors mentioned this pull request Oct 7, 2025

Extend GVN to perform local value numbering. #143333

Draft

cjgillot deleted the gvn-union branch October 7, 2025 10:14

scottmcm reviewed Oct 10, 2025

View reviewed changes

saethlin mentioned this pull request Oct 17, 2025

Fix MaybeUninit codegen using GVN #147827

Merged

GVN: Support unions. #146355

GVN: Support unions. #146355

Uh oh!

Conversation

cjgillot commented Sep 9, 2025

Uh oh!

cjgillot commented Sep 9, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Sep 9, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Sep 9, 2025

Overall result: ❌✅ regressions and improvements - no action needed

Uh oh!

rustbot commented Sep 14, 2025

Uh oh!

cjgillot commented Sep 19, 2025

Uh oh!

jackh726 commented Sep 26, 2025

Uh oh!

bors commented Sep 26, 2025

Uh oh!

bors commented Sep 26, 2025

Uh oh!

This comment has been minimized.

bors commented Sep 26, 2025

Uh oh!

This comment has been minimized.

cjgillot commented Oct 6, 2025

Uh oh!

bors commented Oct 6, 2025

Uh oh!

rustbot commented Oct 6, 2025

Uh oh!

cjgillot commented Oct 6, 2025

Uh oh!

bors commented Oct 6, 2025

Uh oh!

bors commented Oct 7, 2025

Uh oh!

bors commented Oct 7, 2025

Uh oh!

Uh oh!

github-actions bot commented Oct 7, 2025

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Oct 7, 2025

Overall result: ❌ regressions - no action needed

Uh oh!

RalfJung commented Oct 9, 2025

Uh oh!

cjgillot commented Oct 9, 2025

Uh oh!

RalfJung commented Oct 9, 2025 via email

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants