GVN: Bail out if the address cannot be dereferenced.

[dianqk]

Fixes #141313 and #141313 (comment).

We should always use VnIndex when dereferencing an address in GVN.

r? cjgillot
r? tmiasko (since you found that)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[dianqk]

I don't have a test for projection, but projection should also be able to invalidate values.

[dianqk]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: c5a0b2c (c5a0b2c28ca4b44acfc5036fac4e8a95025e5fe4, parent: c8a31b780d5415358566a20b94912620a3f27067)

[cjgillot]

I'm a bit worried we are not addressing the root issue.

We can reason with the value behind a reference because it is UB to directly assign to the underlying local while the reference is live. We allow creating new derefs, this means extending the liveness of references, so we are creating UB.

Should we just ban introducing new derefs?

[rust-timer]

Finished benchmarking commit (c5a0b2c): 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
Regressions ❌ (secondary)	0.2%	[0.0%, 0.3%]	2
Improvements ✅ (primary)	-0.5%	[-0.5%, -0.5%]	1
Improvements ✅ (secondary)	-0.4%	[-1.1%, -0.1%]	4
All ❌✅ (primary)	-0.5%	[-0.5%, -0.5%]	1

Max RSS (memory usage)

Results (secondary 3.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.4%	[2.0%, 6.0%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -1.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)	6.5%	[2.5%, 9.7%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.1%	[-10.5%, -1.6%]	10
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.0%, 0.1%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.1%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.2%, 0.1%]	7

Bootstrap: 473.714s -> 474.328s (0.13%)
Artifact size: 390.54 MiB -> 390.33 MiB (-0.05%)

[dianqk]

I'm a bit worried we are not addressing the root issue.

We can reason with the value behind a reference because it is UB to directly assign to the underlying local while the reference is live. We allow creating new derefs, this means extending the liveness of references, so we are creating UB.

Should we just ban introducing new derefs?

Closing in favor of #147886.