Avoid accessing HIR from MIR passes

[cjgillot]

hir_owner_nodes contains a lot of information, and the query result is typically dirty. This forces dependent queries to be re-executed needlessly.

This PR refactors some accesses to HIR to go through more targeted queries that yield the same result.

Based on #95435 and #95436

[rust-highfive]

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[rust-highfive]

r? @wesleywiser

(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 433197aa622b98c66102db69c5470e927272ba0c with merge ad478adbe52aeca09eb203fb2e6b059054a66ef0...

[bors]

💔 Test failed - checks-actions

[tschuett]

LLVM tried to reduce memory consumption: https://reviews.llvm.org/D111105

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 3ab00b6099549cee9ae116158615d509c699987d with merge e1983f64e110a75b26ac533a88c0530b287f0512...

[cjgillot]

LLVM tried to reduce memory consumption: https://reviews.llvm.org/D111105

What do you mean? Did you mean to post on another PR?

[tschuett]

Do you still need HIR when you are doing MIR passes?

[cjgillot]

I would love to drop HIR once THIR is built. However, the way to go there obscure.

We may access HIR directly for diagnostic purposes. We may also access it indirectly through more targeted queries that have not been computed yet.

Because of the way the compiler and incremental compilation is structured, we don't really have a way to discover those accesses statically. I relied on manual investigation using RUST_FORBID_DEP_GRAPH_EDGE debugging env variable.

[bjorn3]

We do already drop the entire TyCtxt after generating llvm ir is done and while optimization passes are running in background threads. As @cjgillot meantioned being more eager with dropping things is not that easy unfortunately.

[bors]

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

[rust-timer]

Queued e1983f64e110a75b26ac533a88c0530b287f0512 with parent bb5c437, future comparison URL.

[rust-timer]

Finished benchmarking commit (e1983f64e110a75b26ac533a88c0530b287f0512): comparison url.

Summary: This benchmark run shows 6 relevant improvements 🎉 but 5 relevant regressions 😿 to instruction counts.

• Arithmetic mean of relevant regressions: 0.6%
• Arithmetic mean of relevant improvements: -0.3%
• Arithmetic mean of all relevant changes: 0.1%
• Largest improvement in instruction counts: -0.4% on incr-full builds of many-assoc-items check
• Largest regression in instruction counts: 1.0% on incr-full builds of externs 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. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

[oli-obk]

r? @oli-obk

[bors]

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

[oli-obk]

@bors r+

[bors]

📌 Commit bbacfcb has been approved by oli-obk

[bors]

⌛ Testing commit bbacfcb with merge 027a232...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 027a232 to master...

[rust-timer]

Finished benchmarking commit (027a232): comparison url.

Summary:

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

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	0	9	1	0	1
mean2	N/A	0.5%	-0.6%	N/A	-0.6%
max	N/A	0.9%	-0.6%	N/A	-0.6%

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

@rustbot label: -perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩