GVN: consider constants of primitive types as deterministic

[cjgillot]

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]

@bors try @rust-timer queue

[rust-bors]

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

[rust-timer]

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]

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]

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

[cjgillot]

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".