super_relate_consts: stop being generic

[lcnr]

I previously attempted this in #78288 where it slightly improved perf and bootstrap times.

With #99730 changing BoundVarReplacer to use a type parameter instead of a trait object, this may now be even more effective. Relating ConstKind::Value was a large part of this function in the past, which may reduce the impact of this change tough.

r? @jackh726

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 9bcf682f0bf962ec27630cc9c0adc829cd97d32e with merge 34427f20790cbf9f8387dd5a31e2de71d5466fd6...

[bors]

☀️ Try build successful - checks-actions
Build commit: 34427f20790cbf9f8387dd5a31e2de71d5466fd6 (34427f20790cbf9f8387dd5a31e2de71d5466fd6)

[rust-timer]

Queued 34427f20790cbf9f8387dd5a31e2de71d5466fd6 with parent 25bb1c1, future comparison URL.

[rust-timer]

Finished benchmarking commit (34427f20790cbf9f8387dd5a31e2de71d5466fd6): comparison url.

Instruction count

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-0.9%	-1.7%	7
All 😿🎉 (primary)	N/A	N/A	0

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvement found

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

Cycles

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvement found

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

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

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-review -S-waiting-on-perf -perf-regression

Footnotes

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

2. number of relevant changes ↩ ↩² ↩³

[pnkfelix]

Hmm, comparing the bootstrap times from PR 99730 to the bootstrap times on PR 100016, it seems like 99730 regressed bootstrap times by ~2%, but this PR failed to recover that loss (it only improves bootstrap times by 0.11%).

I'll try to dig a little bit more into the specific data reported, just wanted to point out that this change made by PR #100016 may not be the way to address the root cause of the bootstrap time regression .

[jackh726]

For the bootstrap regression in #99730, I think we likely need to consider going back to dynamic dispatch, instead of static. It's a trade off between compiler compile times and overall compile times.

This I think is dependent on that decision.

[lcnr]

alright, with #101857 merged, let's try this again

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout shrink_relate (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self shrink_relate --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Adding src/tools/rls/src/main.rs
Adding src/tools/rls/README.md
Adding src/tools/rls/Cargo.toml
Auto-merging compiler/rustc_middle/src/ty/relate.rs
CONFLICT (content): Merge conflict in compiler/rustc_middle/src/ty/relate.rs
Automatic merge failed; fix conflicts and then commit the result.

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 781cfcd with merge 3374e3a25403f810abbddcb3160b375b60ffc237...

[bors]

☀️ Try build successful - checks-actions
Build commit: 3374e3a25403f810abbddcb3160b375b60ffc237 (3374e3a25403f810abbddcb3160b375b60ffc237)

[rust-timer]

Queued 3374e3a25403f810abbddcb3160b375b60ffc237 with parent 7a8636c, future comparison URL.

[rust-timer]

Finished benchmarking commit (3374e3a25403f810abbddcb3160b375b60ffc237): comparison URL.

Overall result: no relevant changes - 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-review -S-waiting-on-perf -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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

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

Footnotes

1. the arithmetic mean of the percent change ↩

2. number of relevant changes ↩

[lcnr]

alright, looks like this is pretty much irrelevant now 😁