Move OnDiskCache to rustc_query_impl.

[cjgillot]

This should be the last remnant of the query implementation that was still in rustc_middle.

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 97f5a40109c71a722d059fd1ffac8d86820aeb94 with merge 80ff6e6d03c2115be287fa6ce7b94ba7c1e3dcd7...

[bors]

☀️ Try build successful - checks-actions
Build commit: 80ff6e6d03c2115be287fa6ce7b94ba7c1e3dcd7 (80ff6e6d03c2115be287fa6ce7b94ba7c1e3dcd7)

[rust-timer]

Queued 80ff6e6d03c2115be287fa6ce7b94ba7c1e3dcd7 with parent a435b49, future comparison URL.

[rust-timer]

Finished benchmarking try commit (80ff6e6d03c2115be287fa6ce7b94ba7c1e3dcd7): comparison url.

Summary: This change led to significant improvements 🎉 in compiler performance.

• Moderate improvement in instruction counts (up to -4.1% on incr-unchanged builds of ctfe-stress-4-check)

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. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[bors]

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

[bors]

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

[bors]

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

[estebank]

r=me after rebasing

[cjgillot]

@bors r=estebank

[bors]

📌 Commit 5b92150 has been approved by estebank

[bors]

⌛ Testing commit 5b92150 with merge 1807305...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank
Pushing 1807305 to master...

[pnkfelix]

Just a heads up: The perf run that we got after this landed on nightly did not come out quite as rosy as what was predicted from the perf run done locally.

Namely, I see a lot of (small) regressions across several benchmarks, and very few wins at all.

Is there a reason for the different in what we expected from the local run versus what we actually got?

[Mark-Simulacrum]

Investigation with cachegrind here is a little difficult: the movement to trait methods (instead of inherent) and a number of other, similar, changes means that the function paths differ sufficiently from run to run that mapping them is hard. That said, some sed'ing and such to adjust seems to point at most of the small regressions here being largely a result of low-level changes in instruction counts scattered across many of the moved functions.

I suspect this is largely due to the movement across different crates creating a slightly different inlining environment and changing optimizer decisions. A diff of one of the moved functions disassembly shows a lot of changes, and the new version is a little longer (-287, +305).

It's also worth noting that the new significance algorithm which more effectively ignores noise on every statistic we collect shows only one benchmark regressing in wall times. This PR also did lower bootstrap time -- overall by 6 seconds -- which is not much, but still a nice improvement. I think that means that the regressions (which are small) are justified.

@rustbot label +perf-regression-triaged

[tgnottingham]

As with #70951, I assume that some of these regressions would be solved by full program devirtualization (#68262).