Label everything the stacks can name, and add the axis they could not

[zmaril]

A follow-up to #36, measured after it merged. Four commits: leave nothing in
the phase tables that a stack could have named, then add the column for the
thing the phase tables structurally cannot say.

1. The optimiser arriving without its pass manager

#36 drove unattributed from 5.1% to 0.09% — but that was measured on bun's
dev build. On the release build it sat at 0.75%, nearly all of it
loop strength reduction: LLVM enters that pass through a free function and
the unwinder does not get past it, so there is no pass manager on the stack
and no LLVMRustOptimize above it. At -O0 the pass never runs, which is
why the dev build showed none of it. Release: 0.75% → 0.06%.

2. The third level, everywhere it was thin

A quarter of a release build's samples sat at a phase with no detail under
them. Sweeping every phase at once rather than one at a time, what was in
there was passes with names.

phase	bare before	after
optimize	10.7%	0.7%
machine_code	5.0%	1.1%
metadata_encode	2.8%	—
mir_build	1.5%	—
macro_expand	1.5%	—
overall	~25%	2.8%

Three of the new details answer questions nobody could ask before:
macro_expand / proc_macro separates the macro's own code (syn,
quote) from what rustc did around it; metadata_encode / mir_transform
shows that writing a crate's metadata spends more time running MIR passes
than writing anything; ir_build / declare is the symbol names and ABIs
paid before any body is filled in.

3. The other axis

Segment, phase and detail are three grains of one question — why was the
compiler here — and they nest. There is a different question that does not
nest with them, so it gets a column rather than a fourth level: what was
running, taken from the leaf frame alone, null when the sample was inside a
compiler pass doing that pass's own work.

It earns the column because the answer is "not a compiler pass" 24% of the
time on a release build and 45% on a debug one, and none of it was visible:
it is spread across two dozen phases in slices too thin to notice, and the
phase it is spread across is never wrong — optimize really was optimising,
inside a DenseMap.

concern	release	debug
pass_manager	6.5%	0.8%
alloc	5.0%	3.9%
hashmap	4.8%	5.9%
memcpy	2.8%	7.0%
intern	2.1%	5.7%
query	1.3%	4.5%
io	0.8%	11.6%
hash	0.2%	3.5%
dep_graph	—	0.3%
total	24.2%	45.0%

A release build's largest single concern is LLVM choosing what to run next. A
debug build's is the machine waiting on its disk, which no compiler flag
addresses.

The rule is the weak one, on purpose

A concern is the leaf frame or nothing. The stronger rule — a named
concern claiming everything beneath it — was measured and rejected: across
ten concerns it moved every one by less than a percentage point except
dep_graph, which moved seventeen-fold. That single number is its entire
case, and it is the one to trust least, because claiming a subtree from an
enclosing frame is how pass_manager first measured 57% of a build. The
pass manager is on the stack of every sample the optimiser takes, so "matched
anywhere" meant "matched always".

A test pins it: a sample inside InstCombine is instcombine with no
concern, even with the pass manager one frame up.

dep_graph is the joke of it

The concern that prompted the axis is the smallest thing in it — 0.3% of a
debug build, zero on release. What it cannot answer, what incrementality
costs, wants a build run twice with the elapsed times compared. That is a
thing this census is shaped to do across many builds and no attribution of a
single run can replace it.

Measured, not assumed

• Orthogonality. Adding the axis moved exactly three rows: the hash
  detail, 852 samples, redistributed into lower/typeck/encode in the
  same phases. 852 out, 852 in, nothing crossed a phase boundary. Summing
  over concern gives the phases back.
• emit (the write syscall) is matched innermost and could have taken
  samples from asm. In machine_code it took none — 18,901 before and
  after. In link it took 11,860 off archive and left it 732, so it was
  reverted there. A leaf marker is only safe where the leaf is all there is.
• codegen carrying debug_info moved 4.3% of a debug build out of the
  leftover bucket without changing what its neighbours report.

Verification

Measured on clean release and debug builds of bun (99 workspace crates,
lto = "fat", codegen-units = 1): 730,142 and 394,791 samples, plus a
self-build for the new column. cargo test, cargo clippy --all-targets,
cargo fmt --check and the worker suite are clean. phases.parquet grows
from ~8k to ~19k rows on a real build, still under half the span table.

🤖 Generated with Claude Code

https://claude.ai/code/session_015iY4ffQbZC8ix4g4fs1BR5

[github-actions]

cratebank preview

Preview removed because this pull request is closed.