[experiment, do not merge!] rewrite the DenseBitSet structure to only use 1 word on the stack

[tage64]

Modify DenseBitSet in the rustc_index crate so that it only uses one word on the stack instead of 4 words as before, allowing for faster clones. The downside is that it may at most store 63 elements on the stack as aposed to 128 for the previous implementation.

r? lqd

This is experimental so far and I mostly want a perf run to measure
the performance.

[rustbot]

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[lqd]

(sorry for the unintended pings, everyone)

cc @nnethercote this is the bitset work I was telling you about. It did look interesting in my tests, ~= 0.5% wins on a lot of primary benchmarks.

let's see if a try build works:

@bors try @rust-timer queue

[bors]

⌛ Trying commit 3ff2c88 with merge 693ccca...

[nnethercote]

Looks interesting. Unfortunately being a single commit makes it incredibly hard to review, especially with so much code being moved into dense_bit_set.rs. If it gets beyond the draft stage I think the commits need to be structured differently to make review easier. E.g. the code doesn't need to move into dense_bit_set.rs, or if that's really desired, it should be moved in a first commit and then modified in a second commit. And any other changes are made that are independent (e.g. changing MixedBitSet::Small to Self::Small) can be done in separate commits as well.

[lqd]

Yeah this is just for the perf run I think. The branch I was looking at (now unfortunately gone) had many smaller commits that were easier to review, eg the last 20 of master...tage64:rust:replace_predecessors

[tage64]

I squashed all commits into one to make rebasing on upstream easier. Maybe that was not necessary but as you said, this is just for experiments. The original commit history is still there in tage64/rust@thin_bit_set_old.

[bors]

☀️ Try build successful - checks-actions
Build commit: 693ccca (693cccaceb81d959dbf823da027464c8655b8b57)

[rust-timer]

Finished benchmarking commit (693ccca): comparison URL.

Overall result: ✅ improvements - 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.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-0.5%	[-1.1%, -0.1%]	83
Improvements ✅ (secondary)	-1.0%	[-3.3%, -0.1%]	50
All ❌✅ (primary)	-0.5%	[-1.1%, -0.1%]	83

Max RSS (memory usage)

Results (primary -1.1%, secondary -1.3%)

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)	0.8%	[0.8%, 0.9%]	2
Improvements ✅ (primary)	-1.1%	[-1.1%, -1.1%]	1
Improvements ✅ (secondary)	-2.4%	[-5.2%, -0.4%]	4
All ❌✅ (primary)	-1.1%	[-1.1%, -1.1%]	1

Cycles

Results (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)	-	-	0
Regressions ❌ (secondary)	1.8%	[1.5%, 2.1%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-2.0%, -0.7%]	6
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%, 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.0%	[0.0%, 0.1%]	48
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	25
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.1%]	48

Bootstrap: 775.275s -> 774.785s (-0.06%)
Artifact size: 365.51 MiB -> 365.51 MiB (0.00%)