Skip finish passes over functions that cannot hold their nodes

What this does

finishModule runs about fifteen whole-program IR walks back to back, and most of them look for a rare node kind or library entry point that a given function does not hold at all. On pi's build that is 42K functions walked fifteen times to find nothing, and every walk that rewrites copied each node it passed through. This is WP2-7 of the pi build-speed plan.

Census. A FunctionCensus records, per function and in one scan, the expression kinds, statement kinds, libCall entry points and intrinsics of the body. Each finisher asks the census whether a function can hold what it looks for and skips the rest. The filters list every kind the finisher reacts to, including constructor values that arrive through dynFrom, and routeWrapperConsumers now tests for the two entry points and two intrinsics it routes instead of for any library call at all (which almost every function holds). The census is validated the way DispatchSites validates its summaries: same statement-list array, same length, same first and last statement. A pass that changes a node inside an unchanged list calls forget, and a pass that rewrites nodes in place clears the census. SCRIPTC_CHECK_FUNCTION_CENSUS=1 rescans and compares on every reuse.

Sharing. Inside the module finish (withStructureSharing), a rewrite that leaves a node's children unchanged returns the node itself instead of a copy, and mapOf, mapValues, mapKeyValues and mapCases return their input when no element changed. Outside that window every case still rebuilds its node, because lowering needs that: settleSharedHelperLocations retags shared helper nodes' locations in place. Visitation order is unchanged, so local ids, IR and LLVM are unchanged.

Stack frame. mapExprChildren and mapStmtChildren are on the native stack once per nesting level of every recursive rewrite, and an unoptimized build gives every local, comparison and conditional result its own stack slot. Each case therefore computes its children into a few function-level slots and asks a leaf predicate (kept, kept2 to kept4) whether they came back unchanged. Measured in the sanitized dev build of the self-hosting emitter:

The first version failed the sanitized emitter bootstrap's fixed point with RangeError: Maximum call stack size exceeded after 70 nested frames; on main that run already uses between 3.8 and 4.6 MB of its 6 MB of usable stack.

Proof

Everything below ran on 0e9c39e73, this commit on 714482d49. The branch head is the same commit rebased onto 7954cf5d4 without conflicts; the four PRs in between touch the type mapper, lint rules, generic class fields and CI.

Zero-cost gate

bin/validate --skip=lanes,bench,t262,san-bootstrap --gate-corpus=all against 714482d49:

validate fix-pi-speed-wp2-5-7 @ 0e9c39e73 vs 714482d49: PASS in 23.4m
jobs: gate-1..6, gate-fixture, gate-self-1..4 (11 jobs, 32 vCPU each)

PASS  zero-cost gate
      time       bench geomean +0.63% [95% CI -0.43%, +1.51%]: within tolerance
      time       self -1.60% [95% CI -2.63%, -0.26%]: within tolerance
      time       fixtures geomean -0.47% [95% CI -0.81%, -0.12%]: within tolerance
      self       candidate compiler source builds with the candidate (671.14s)
      zero-cost gate: PASS - 5176 identical, 96 both-fail over 8 shards

Every program, JavaScript corpus and npm suite included, is byte-identical in IR, LLVM and release executable. There are no differing rows and no runtime-only rows, and no --gate-allow pattern was used. Compiling the compiler with itself got 1.6% faster.

Bootstraps

All four run on this commit's tree in 32 vCPU / 64 GB sandboxes:

The sanitized emitter fixed point is the one the first version failed. The emitter built the way that test builds it (dev, ASan) also emits its own IR with a 6144 kB stack, the smallest of the limits tried at which main's does (both fail at 5120 kB).

Tests

• pnpm vitest run packages/compiler: 544 files passed, 2 skipped; 5087 tests passed, 29 skipped, none failed. That includes the new function-census.test.ts.
• pnpm lint: 0 warnings, 0 errors. pnpm format:check: clean. pnpm test:ts7 --baselines-only: every fixture has a baseline.

pi build

pi e770f5efe, entry packages/coding-agent/src/cli.ts, --npm-static (15 packages), --node-islands=auto, compiler run under Node from packages/cli/dist. Two sandboxes of 32 vCPU / 64 GB, both Intel(R) Xeon(R) Processor @ 2.90GHz; trees alternate on each sandbox.

(A tree copy and a 20 s TypeScript build ran beside c14, three minutes into it. The second sandbox slowed down over its session, load phase included; its runs of a third tree, not part of this PR, sat between the ones shown.)

• Peak memory is the effect: -28% on w59 (7.43 to 5.36 GiB) and -27% on the second sandbox (7.39 to 5.43 GiB). Every run of this PR (5.03 - 5.60 GiB) is below every run of main (6.97 - 8.17 GiB): the finish passes no longer copy every node they pass through.
• Build time on pi is unchanged within the noise. The means differ by -0.9% wall on w59 and -0.2% on the second sandbox, and runs of the same tree differ by 6% to 11%. The plan estimated 20 to 30 s for this package; pi's wall clock does not show it.
• Diagnostics are identical. Every run reports 66 errors, and the diagnostics text of every run of this PR is byte-identical to main's (everything the build prints except its timing lines).

The compiler compiling itself, which the gate times in four base/candidate pairs, is 1.6% faster (95% CI -2.63% to -0.26%).

SCRIPTC_CHECK_FUNCTION_CENSUS=1 ran one full pi build on the previous revision of this branch (same census code): every reuse of a census rescanned the body, none had gone stale, and the diagnostics were unchanged.

🤖 Generated with Claude Code