Several small span improvements

[nnethercote]

Limit changes:

• Increase MAX_CTXT: it is currently 0b0111_1111_1111_1110 (~15 bits). But it only needs to be distinguishable from CTXT_INTERNED_MARKER (all 1s). So we can increase it to 0b1111_1111_1111_1110 (~16 bits). The old limit is rarely reached; the uom crate is an exception (it has 39k contexts) and we see a 1-2% instruction count reduction when building it. (This value was incorrectly reduced from ~16 bits to ~15 bits in e525e4f by me; apologies!)

Renamings:

• Rename MAX_CTXT as MAX_CTXT_OR_PARENT because it also relates to the parent field.
• Remove the BASE_ prefix from BASE_LEN_INTERNED_MARKER because it doesn't mean anything.

Comments:

• Update parts of the comment that predate the addition of the parent field, such as the frequency measurements. (In incremental builds, 20-40% internment due to non-root context and non-zero parent is common.)
• Slightly clarify the meanings of the fields in the different forms, and add a paragraph quickly explaining which specific values distinguish the four forms.

r? @petrochenkov

[nnethercote]

Not expecting this to affect any of the benchmarks in rustc-perf, but let's check:

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: d8d8cda (d8d8cdade7030ea9ece504a046a83b80ab170288)
Base parent: 012c0bd (012c0bd4d516934012c9a1ecb26e9eb283d2ed75)

[rust-timer]

Finished benchmarking commit (d8d8cda): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.1%	[0.1%, 0.1%]	6
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.1%, -0.1%]	1

Max RSS (memory usage)

Results (secondary -3.5%)

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)	-3.5%	[-3.5%, -3.5%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 6.8%)

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)	6.8%	[6.2%, 7.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.746s -> 497.016s (1.28%)
Artifact size: 406.55 MiB -> 406.57 MiB (0.01%)

[nnethercote]

Not sure why the tiny tt-muncher regressions occur; the only code change in this PR is the changing of that one constant. The cachegrind diff says the difference is mostly in parse_token_tree. Smells like random fluctuations to me.

[petrochenkov]

@bors r+ rollup

[rust-bors]

📌 Commit 13b380d has been approved by petrochenkov

It is now in the queue for this repository.

[rust-timer]

Note

This PR was benchmarked as part of triage of its containing rollup: triage URL.

Finished benchmarking commit (04c3c2a): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.2%	[0.1%, 0.4%]	9
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-0.5%	[-0.5%, -0.4%]	2
All ❌✅ (primary)	-0.1%	[-0.1%, -0.1%]	1

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (secondary -3.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)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: missing data
Artifact size: 408.61 MiB -> 408.67 MiB (0.02%)

[JonathanBrouwer]

The typenum regression might be real or it might not be, it's hard to tell through the noise

[nnethercote]

As above, the tiny perf effects are just random codegen fluctuations.