Runs the control 06531fb named. It settles the question that commit left open,
and the answer is that the enrichment is real.
Matching on immediate-set size, against the best of the sixteen adjacent values:
bucket n 0xc0 best neighbour ratio
0-15 1,082 72 0xb8:1 72.0x
16-31 713 119 0xc8:4 29.8x
32-47 291 104 0xb8:3 34.7x
48-63 119 39 0xb8:2 19.5x
64-79 59 31 0xc8:2 15.5x
80-95 25 13 0xb8:1 13.0x
Enriched in every bucket, and the ratio does not decay as sets grow. That is the
opposite of a pigeonhole artifact -- a volume effect would shrink the ratio in the
big buckets, and it rises instead.
The load-bearing row is the smallest: 72 of 1,082 functions carrying fewer than 16
distinct immediates contain 0xc0, where the best neighbour appears once. A set that
small cannot produce that by count alone.
What this revives. The 300 candidates with 48 or fewer distinct immediates are not
noise: at matched size, neighbours hit 0.4% to 1.4% in those buckets where 0xc0
hits 35%. A function using fewer than 16 constants, one of which is 0xc0, uses
that offset deliberately. Those are the shortlist.
Why this took four commits to establish. 3ea5ab7 measured 394 against neighbours
1-14 and called it a shortlist. 06531fb showed the rate rises with set size and
said the 394 was a list of large functions. Both were right about their own
measurement and neither had the bucket-matched comparison, which is the only form
that separates "the constant is special" from "big functions contain more
constants". Twenty-two probes this stretch, and the thing that finally settled it
was not a better measurement but adding the right comparison to a measurement
taken three commits earlier.
Caveat unchanged: presence of an immediate is not proof the chunk is read there.
It is proof the constant is used, which is all either test asserts.
284 passing with the disc present (23 + 19 + 64 + 156 + 22; disc binary ~35s),
clippy clean.
ReaperOfVeriod
a2f8c924b4