Exact Type Precision vs Optimization Cost

Start by reviewing the exact-type uses under src/passes/ and the GC-heavy corpus in test/lit/passes/gc.wast. Run the proposed -O3 comparisons with and without early type generalization, then report the corpus, pass, code-size delta, and instruction-count delta; if adopting a utility instead, use the affected passes and verify with python3 check.py lit.

Problem:

#7403 tracked correctness bugs arising from Binaryen's internal use
of refined types (exact heap types, concrete function signatures,
stringref, and similar). @tlively closed it on, noting
that "the correctness bugs are largely fixed here, although
occasionally new ones pop up, e.g. as fixed by #9126."

The remaining concern is a trade-off, not a bug: "our use of exact
types in the IR can sometimes inhibit optimizations (also as seen in
that PR, but also in e.g. TypeSSA), so it's not clear if the extra
precision is worth the cost."

No utility exists to measure this trade-off, and no policy exists
about which passes should generalize before comparing types. Each
pass that runs into the problem solves it locally.

Known inhibited passes / PRs:
TypeSSA. Exact types on locals prevent SSA-ifying values that would
otherwise be candidates.

Known concrete cases:
#9126. A pass had to be fixed because exact types blocked an
optimization. The PR records the specific pattern.

Precision-benefiting passes (not yet enumerated):
Any pass that reads isExact() / getExactness() or compares heap
types for equality in an optimization predicate. Unknown surface;
needs a grep across src/passes/.

Not yet examined:
The full set of passes that compare heap types for equality rather
than for the generalization the binary writer will apply.
The pipeline position where a generalization pass, if introduced,
would do the least harm to precision-consuming passes.
The end-to-end cost: how much code size and instruction count is
lost by carrying precision through the pipeline versus generalizing
early.

Proposed approach:

Two directions, with the choice depending on the measurement.

Direction A — Measure first.
Enumerate the passes that use exact types (grep isExact /
getExactness in src/passes/) and the passes that reject on exactness
(grep for getHeapType() == in optimization predicates). Build a
GC-heavy corpus (test/lit/passes/*gc*.wast plus any real-world
modules available). Run -O3 with and without an early
--type-generalizing (or equivalent). Diff code size and instruction
count. The delta quantifies what precision costs. If the delta is
small, close this issue and handle #9126-style cases locally. If it
is large, move to Direction B.

Direction B — Introduce a generalized-comparison utility.
Add a function that compares two heap types after applying the same
generalization the binary writer applies given the enabled features.
Replace equality comparisons in the passes that know they want
generalization but have no utility for it.

Direction C — Do nothing.
Occasional #9126-style fixes handle regressions as they appear.
Not recommended: @tlively explicitly raised the concern, and the
question is answerable.

Verification per direction:

Direction A: the measurement itself is the deliverable. Report the
corpus, the pass used to generalize, and the code size / instruction
count delta. No lit test change.

Direction B: for each pass that adopts the utility, add a test
showing a case that is currently rejected on exactness and is
optimized after the change. Execute python3 check.py lit command.

Follow-up:

Direction A's measurement determines whether Direction B is worth
pursuing, and at what pipeline position. If Direction A shows the
cost is negligible, this issue closes and #9126-style fixes remain
the policy. If it shows a real cost, Direction B's utility is
scoped in a follow-up PR.

Refs #7403.