Use valtrees as the type-system representation for constant values

[b-naber]

This is not quite ready yet, there are still some problems with pretty printing and symbol mangling and deref_const seems to not work correctly in all cases.

Mainly opening now for a perf-run (which should be good to go, despite the still existing problems).

r? @oli-obk

cc @lcnr @RalfJung

[rust-highfive]

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[oli-obk]

Unfortunately we need rustdoc to compile for perf runs

[oli-obk]

Let's see if this works. Maybe run ./x.py check in future PRs that touch datastructures in librustc_middle, as I'm not sure what else is needed for try builds

@bors try

[bors]

⌛ Trying commit da9d68309443e7dd3afb9e0096db0ee8e4f55aa9 with merge 5db5e4101a6e3a17679a4ac488690c36745b53b8...

[bors]

💔 Test failed - checks-actions

[oli-obk]

Let's see if this works

nope 😆 all tools need to build at least

[b-naber]

^^

Should work now. x.py check works. And before the changes to clippy and cranelift I was able to build stage2 with incremental turned off.

[oli-obk]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 7add06c03661a556e0eed1810d34d5f7f5b46f84 with merge 2b7377c196716fe4ec48ba949e509046e307ee32...

[b-naber]

@bors r=lcnr

[bors]

📌 Commit 15c1c06 has been approved by lcnr

[bors]

⌛ Testing commit 15c1c06 with merge 1f34da9...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 1f34da9 to master...

[rust-highfive]

📣 Toolstate changed by #96591!

Tested on commit 1f34da9.
Direct link to PR: #96591

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).

[rust-timer]

Finished benchmarking commit (1f34da9): comparison url.

Instruction count

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	0.4%	0.6%	54
Regressions 😿 (secondary)	3.1%	14.3%	29
Improvements 🎉 (primary)	-3.0%	-5.9%	10
Improvements 🎉 (secondary)	-1.1%	-1.6%	7
All 😿🎉 (primary)	-0.2%	-5.9%	64

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regression found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	2.2%	2.2%	1
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	N/A	N/A	0

Cycles

Results

• Primary benchmarks: 🎉 relevant improvements found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	12.8%	16.5%	7
Improvements 🎉 (primary)	-3.8%	-5.6%	6
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	-3.8%	-5.6%	6

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[oli-obk]

The primary regressions are most likely noise or due to additional query encodings in incremental.

The big regression is the CTFE stress test, which, considering this PR heavily modifies how constants are handled, is somewhat expected. We're stress testing the worst case path: evaluating a constant to a valtree and then turning it back into an evaluator value without ever really needing the valtree value.

[ecnelises]

For commit e14b34c , the two to_le() actually produces different result on big-endian from little-endian.

// Note: Don't use `StableHashResult` impl of `u64` here directly, since that
// would lead to endianness problems.
let hash: u128 = hasher.finish();
let hash_short = (hash.to_le() as u64).to_le();

Assume hash: u128=0x5e0f03940fda80bb6348c650c7b26618, then on LE, hash_short: u64 = 0x6348c650c7b26618, while BE hash_short: u64 = 0x5e0f03940fda80bb, which fails some unit tests on big endian targets because of hash mismatch.

If it's expected behavior to make hash value the same on BE/LE, code here should remove two to_le calls. We don't need to adjust endianness unless converting between multi-byte integer and byte sequences.

[b-naber]

If it's expected behavior to make hash value the same on BE/LE, code here should remove two to_le calls. We don't need to adjust endianness unless converting between multi-byte integer and byte sequences.

I don't remember exactly what was going on (and I'd hate to read into this again), but we did need those calls in order to pass the debug tests on i686-msvc-1. Feel free to open a PR that removes those calls, though unless something else changed I don't think those tests will pass on that machine.