mir opt + codegen: handle subtyping #112307

lcnr · 2023-06-05T11:12:02Z

the same issue was caused in multiple places:

mir opts: both copy and destination propagation
codegen: assigning operands to locals (which also propagates values)

I changed codegen to always update the type in the operands used for locals which should guard against any new occurrences of this bug going forward. I don't know how to make mir optimizations more resilient here. Hopefully the added tests will be enough to detect any trivially wrong optimizations going forward.

rustbot · 2023-06-05T11:12:08Z

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2023-06-05T11:12:12Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

lcnr · 2023-06-05T12:19:10Z

@bors try @rust-timer queue

bors · 2023-06-05T12:19:20Z

⌛ Trying commit b47112e337af38985998a9c2cb8b0663da9bfdee with merge 688ecdd88c9c98c0dd3ed5f53d5180535c63086b...

compiler/rustc_mir_transform/src/dest_prop.rs

compiler/rustc_codegen_ssa/src/mir/operand.rs

bors · 2023-06-05T14:16:39Z

☀️ Try build successful - checks-actions
Build commit: 688ecdd88c9c98c0dd3ed5f53d5180535c63086b (688ecdd88c9c98c0dd3ed5f53d5180535c63086b)

rust-timer · 2023-06-05T16:02:36Z

Finished benchmarking commit (688ecdd88c9c98c0dd3ed5f53d5180535c63086b): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.9%	[1.9%, 1.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.7%	[-5.2%, -4.2%]	5
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 646.615s -> 645.351s (-0.20%)

lcnr · 2023-06-09T11:22:03Z

@bors try @rust-timer queue

bors · 2023-06-09T11:22:13Z

⌛ Trying commit a4fc594dfeaa7cee6b4aa2769ab282b183a7eaf7 with merge 26bd1b92367a2173690199389c3e1e44a1ce759b...

lcnr · 2023-06-09T11:37:49Z

@bors try @rust-timer queue

lcnr · 2023-06-15T09:47:56Z

yeah, agree with that 👍 we should add a mir pass post analysis which makes subtyping explicit, opened #112651 for that. I don't have the capacity to actually implement this though, so I would like for someone else to take that over.

I would still like to merge this PR (putting a FIXME(#112651) at every place which should be changed once subtyping is explicit) given that it still fixes the unsoundness. I also think that extracting Locals into a private module is a positive change regardless. Checking the type of LocalRef::Operand detected another 'bug' (using wrong types in shims) and we can change overwrite_local to assert that the types are equal instead afterwards.

does this seem sensible to you @cjgillot?

cjgillot · 2023-06-18T14:56:24Z

I agree to do it that way.

lcnr · 2023-06-19T07:21:22Z

add a bunch of FIXME(#112651) to everything that should be changed/reverted after #112651.

@rustbot ready

compiler-errors

Everything looks good.

compiler-errors · 2023-06-27T16:55:53Z

@bors r+

bors · 2023-06-27T16:55:55Z

📌 Commit 46973c9 has been approved by compiler-errors

It is now in the queue for this repository.

bors · 2023-06-28T00:41:40Z

⌛ Testing commit 46973c9 with merge bb95b7d...

bors · 2023-06-28T03:17:08Z

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing bb95b7d to master...

rust-timer · 2023-06-28T04:30:50Z

Finished benchmarking commit (bb95b7d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.5%	[-1.5%, -1.5%]	1
Improvements ✅ (secondary)	-2.7%	[-3.6%, -1.8%]	2
All ❌✅ (primary)	-1.5%	[-1.5%, -1.5%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 662.939s -> 662s (-0.14%)

Remove assert that checks type equality rust-lang#112307 although this prevented `unsound` issues it also seems to introduce regressions rust-lang#114858 is example of this regression. I locally tested this rust-lang#114858 (comment) issue and failing assert is [this](https://www.diffchecker.com/cjb7jSQm/). This is also related to rust-lang#115025

Remove assert that checks type equality rust-lang/rust#112307 although this prevented `unsound` issues it also seems to introduce regressions rust-lang/rust#114858 is example of this regression. I locally tested this rust-lang/rust#114858 (comment) issue and failing assert is [this](https://www.diffchecker.com/cjb7jSQm/). This is also related to rust-lang/rust#115025

RalfJung · 2023-11-30T15:59:26Z

compiler/rustc_codegen_ssa/src/mir/locals.rs

+                    op.layout.ty = local_ty;
+                }
+            }
+        };


FWIW in the MIR interpreter we avoid the risk of this by not having the type of the local in our locals map to begin with: we store a IndexVec<mir::Local, LocalState<'tcx, Prov>>, where LocalState is basically just interpret::Operand. When we need the type we always go through body.local_decls.

So that might also be something codegen can do; storing the type in self.locals is redundant.

…fleLapkin explain a good reason for why LocalValue does not store the type of the local As found out by `@lcnr` in rust-lang#112307, storing the type here can lead to subtle bugs when it gets out of sync with the MIR body. That's not the reason why the interpreter does it this way I think, but good thing we dodged that bullet. :)

explain a good reason for why LocalValue does not store the type of the local As found out by `@lcnr` in rust-lang/rust#112307, storing the type here can lead to subtle bugs when it gets out of sync with the MIR body. That's not the reason why the interpreter does it this way I think, but good thing we dodged that bullet. :)

rustbot assigned jackh726 Jun 5, 2023

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 Jun 5, 2023