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

[cjgillot]

@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]

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]

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]

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

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

[RalfJung]

Another reference to the same closed issue

[RalfJung]

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]

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]

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