Skip to content

Census blocker histogram under-ranks any cause with a varying numeric payload — collapse_instance_lists() does not mask immediates #1159

Description

@avrabe

Found by the v0.62 independent cold review (docs/reviews/v0.62-cold-review.md, NOTE 5), deferred out of that release deliberately and filed here so it does not live only in a disposition table.

The defect

partial_census_1017.py's collapse_instance_lists() exists so that one CAUSE buckets as one row in the ranked blocker histogram — symbol lists, export-name lists and global-initializer dumps are collapsed, because they differ per module while naming the same class. That was added in #1156 after a first run fragmented one cause into forty singleton buckets.

It does not mask hex immediates. The reviewer's ARM re-run shows:

encode_operand2: immediate 0x624 ...    (4)
encode_operand2: immediate 0x5dc ...    (1)

as separate buckets for what is one cause.

Why it is worth fixing rather than shrugging at

No number in v0.62 is wrong — the artifact's 5 encode_operand2 total is the correct sum, and the reviewer verified the histograms sum to their decline counts. The script simply does not fully deliver its own stated property.

But the histogram's job is ranking, and v0.63's theme is "raise the percentage, and say which percentage" — with re-measurement as increment 1 and the NEVER bucket broken down by root cause. A cause fragmented across N buckets is systematically under-ranked against a cause that happens to have no varying payload. That is exactly the input the release plans to prioritise from, so a ranking artifact that can under-rank is a planning defect even when every total is right.

Shape of the fix

Extend the existing collapse to mask varying numeric payloads (hex and decimal immediates, offsets, sizes) the same way instance lists are already collapsed — full text preserved in the --json records, as today. Then re-derive: the collapsed histogram's buckets must still sum to the decline count, and the encode_operand2 rows must merge to one.

Why it was NOT fixed in v0.62

Changing a measurement script mid-release-cut, under the oracle it feeds, risks the census for no gain — no v0.62 number depends on it. Recorded in the v0.62 review disposition as carried, not dropped.

Refs #1156, #242

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions