Merge mir query analysis invocations

[oli-obk]

r? @ghost

same thing as #140854 just a different set of queries

Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit d63b394 with merge bddede8...

[bors]

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

[rust-timer]

Finished benchmarking commit (bddede8): comparison URL.

Overall result: ❌ regressions - 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-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.6%, 0.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -0.9%, secondary -2.2%)

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.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.4%, 1.1%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.1%	[-2.7%, -0.5%]	20
Improvements ✅ (secondary)	-2.2%	[-4.0%, -0.4%]	2
All ❌✅ (primary)	-0.9%	[-2.7%, 1.1%]	23

Cycles

Results (primary 1.5%, secondary 0.2%)

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.

	mean	range	count
Regressions ❌ (primary)	1.8%	[0.4%, 3.9%]	26
Regressions ❌ (secondary)	4.5%	[3.2%, 5.4%]	10
Improvements ✅ (primary)	-0.8%	[-1.3%, -0.5%]	3
Improvements ✅ (secondary)	-7.0%	[-7.8%, -6.3%]	6
All ❌✅ (primary)	1.5%	[-1.3%, 3.9%]	29

Binary size

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

Bootstrap: 773.559s -> 774.531s (0.13%)
Artifact size: 365.71 MiB -> 365.58 MiB (-0.03%)

[oli-obk]

@Zoxc do you think changes like this are detrimental to parallel rustc?

[Zoxc]

Merging parallel sections is generally good, but actual measurements are also nice.

[oli-obk]

Right. I'll figure out how to do that locally. But until then

r? @nnethercote

[oli-obk]

Ah no I forgot the regression only shows in cycles, not in instructions...

[oli-obk]

Branch misses and cache misses are also really badly regressed. So my original analysis still stands, even if wall time itself is not really affected

[nnethercote]

Why dump attrs stuff later? I'm not opposed, just there's no motivation given.

[oli-obk]

I wanted to make space there to merge the parallel blocks before and after

[nnethercote]

Branch misses and cache misses are also really badly regressed. So my original analysis still stands, even if wall time itself is not really affected

Can you remind me what the original analysis is? I've lost track of the motivation for this PR. Is it for code simplification, performance, both/something else? Thanks.

[oli-obk]

Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.

[oli-obk]

The reasons I'm doing it is that

• merging those blocks allows for more parallelism as you don't run parallel blocks in sequence
• merging blocks allows merging analysis queries shrinking the dep graph
• should allow us to do more early aborting in case of errors and/or moving query calls from the analysis query into others that allow early aborting the others (and doing more tainting and stuff)

[nnethercote]

The reasons I'm doing it is that

Aha, that helps a lot. Please put that explanation in the commit message for the third commit, and then r=me, thanks.

[oli-obk]

@bors r=nnethercote

[bors]

📌 Commit e011c43 has been approved by nnethercote

It is now in the queue for this repository.

[oli-obk]

@bors retry

[oli-obk]

@bors rollup=never

[bors]

⌛ Testing commit e011c43 with merge d8ccc90...

[bors]

💔 Test failed - checks-actions

[clubby789]

System.IO.IOException: There is not enough space on the disk - @bors retry

[bors]

⌛ Testing commit e011c43 with merge ae6350f...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[oli-obk]

@bors retry

[bors]

⌛ Testing commit e011c43 with merge 16244bc...

[bors]

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing 16244bc to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 777d372 (parent) -> 16244bc (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 16244bc37a6ff610daa38afcddfc1a8bb226702e --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-1: 7371.2s -> 9885.6s (34.1%)
2. dist-apple-various: 6014.7s -> 7659.6s (27.3%)
3. x86_64-apple-2: 4665.0s -> 4171.6s (-10.6%)
4. dist-arm-linux: 4966.9s -> 4503.5s (-9.3%)
5. x86_64-gnu-aux: 6386.8s -> 5905.9s (-7.5%)
6. x86_64-mingw-2: 6744.0s -> 7194.8s (6.7%)
7. x86_64-gnu-nopt: 5471.5s -> 5833.5s (6.6%)
8. x86_64-gnu-stable: 7103.7s -> 6676.9s (-6.0%)
9. x86_64-gnu-llvm-19-1: 5231.5s -> 5506.9s (5.3%)
10. dist-x86_64-apple: 7108.3s -> 7476.2s (5.2%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (16244bc): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	5
All ❌✅ (primary)	-0.1%	[-0.1%, -0.1%]	1

Max RSS (memory usage)

Results (primary -3.1%, secondary 0.1%)

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.0%	[3.0%, 3.1%]	2
Improvements ✅ (primary)	-3.1%	[-6.8%, -1.2%]	3
Improvements ✅ (secondary)	-0.9%	[-1.8%, -0.5%]	6
All ❌✅ (primary)	-3.1%	[-6.8%, -1.2%]	3

Cycles

Results (primary 1.9%, secondary 2.6%)

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.

	mean	range	count
Regressions ❌ (primary)	1.9%	[0.9%, 3.7%]	18
Regressions ❌ (secondary)	2.6%	[0.6%, 4.8%]	18
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.9%	[0.9%, 3.7%]	18

Binary size

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

Bootstrap: 775.816s -> 777.625s (0.23%)
Artifact size: 365.47 MiB -> 365.43 MiB (-0.01%)