use MixedBitSet for borrows-in-scope dataflow analysis

[lqd]

The Borrows dataflow analysis uses a dense bitset, but a bitset supporting some amount of sparseness is better suited for big functions with a big number of loans.

The cutoff between dense and chunked bitset is around 2K loans IIRC, and we could finesse that value if we wanted to, but as-is it happens to a couple of rustc-perf benchmarks (which IIRC are at least partially generated from macros and the likes.). It's a small win on these two, and shouldn't have any impact on the others.

r? @matthewjasper

[lqd]

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit 2554f8f with merge 45305ab…

To cancel the try build, run the command @bors2 try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 45305ab (45305ab33b8806f539a150502a36bbbababe1c23, parent: 0d6ab209c525e276cbe7544cbd39a3c3619b6b18)

[rust-timer]

Finished benchmarking commit (45305ab): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.6%]	2
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.5%]	4
All ❌✅ (primary)	-0.7%	[-0.7%, -0.6%]	2

Max RSS (memory usage)

Results (primary -0.8%, secondary -0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.5%	[1.5%, 1.5%]	1
Regressions ❌ (secondary)	2.8%	[2.8%, 2.8%]	2
Improvements ✅ (primary)	-1.9%	[-2.1%, -1.8%]	2
Improvements ✅ (secondary)	-3.6%	[-6.1%, -1.1%]	2
All ❌✅ (primary)	-0.8%	[-2.1%, 1.5%]	3

Cycles

Results (secondary 7.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Binary size

Results (secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Bootstrap: 755.964s -> 756.42s (0.06%)
Artifact size: 372.26 MiB -> 372.31 MiB (0.02%)

[nnethercote]

@bors r+

[bors]

📌 Commit 2554f8f has been approved by nnethercote

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2554f8f with merge f768dc0...

[bors]

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing f768dc0 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 586ad39 (parent) -> f768dc0 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard f768dc01da9a681716724418ccf64ce55bd396c5 --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-2: 6068.7s -> 3570.2s (-41.2%)
2. aarch64-apple: 5308.6s -> 3706.8s (-30.2%)
3. dist-apple-various: 7570.7s -> 6116.2s (-19.2%)
4. mingw-check-1: 1908.8s -> 1621.7s (-15.0%)
5. dist-aarch64-apple: 5586.0s -> 4807.9s (-13.9%)
6. i686-gnu-2: 6093.2s -> 5334.0s (-12.5%)
7. x86_64-gnu-llvm-20-2: 6195.0s -> 5447.1s (-12.1%)
8. dist-i686-mingw: 7710.8s -> 8622.3s (11.8%)
9. i686-gnu-nopt-1: 7999.3s -> 7114.8s (-11.1%)
10. x86_64-rust-for-linux: 2904.2s -> 2598.8s (-10.5%)

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 (f768dc0): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.6%]	2
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	5
All ❌✅ (primary)	-0.7%	[-0.7%, -0.6%]	2

Max RSS (memory usage)

Results (primary -1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.9%	[-2.0%, -1.8%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.9%	[-2.0%, -1.8%]	2

Cycles

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

Binary size

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

Bootstrap: 755.712s -> 756.159s (0.06%)
Artifact size: 372.06 MiB -> 372.14 MiB (0.02%)