25.16 MB of the cc binary is LITERAL ZEROS: inline caches emitted as zeroinitializer globals land in __data instead of __bss — 8.2% of the file for free #9610

From the byte-exact binary census of the cc build (segment sum reconciles to stat with 0 B delta; full tables: https://claude.ai/code/artifact/b4a23066-fdf9-47f4-92ae-bbad2aba4285).

__data is 25,159,016 B of which 99.5% is zeros — only 15,748 of 3,144,877 words are nonzero. Traced to one emission site: crates/perry-codegen/src/function.rs:1460 emits each inline cache as private global [12 x i64] zeroinitializer — 96 B each, and 25,159,016 ÷ 96 = 262,073.08 caches. All-zero at link time, but placed in file-backed __data rather than zero-fill __bss, so every one of those zero bytes is stored in the file (and paged/COW'd at load).

Fix shape: make the IC globals land in __bss — either emit them as zero-initialized globals the linker is allowed to put in bss (check what attribute/section placement perry's LLVM emission needs; internal global … zeroinitializer normally does go to bss, so find what forces these into data — an explicit section? an initializer that only folds to zero at link? alignment grouping?), or emit one big bss array indexed by IC id. 8.2% of the 307 MB file, zero runtime behaviour change — the cheapest binary-size win available by an order of magnitude (for calibration: full ICF folding was measured at 0.05–0.72%).

Verification: binary size delta ~25 MB; size -m shows __data shrunk and __bss grown by matching amounts; the gap suite unchanged; a cc build boots and passes the stress smoke set (ICs are correctness-critical — the #9367 lesson says verify cache HITS still occur, e.g. via the IC-census/trace knob, not just green output).

Also recorded from the same census, for future size work: generated JS is 63% of the file (193.9 MB) with a long-tail distribution (top 1,000 functions = 33%; 50,000 needed for 94%) — so per-function size work doesn't pay; only structural emission changes like this one do. Rust archives total just 7.3%.