Exact Type Precision vs Optimization Cost

@tlively

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.

@tlively

@tlively. Looked into the measurement for the trade-off. Two blockers,
both worth flagging before spending more time on a benchmark.

1. There is no sound early-generalizing pass to compare against.
createTypeGeneralizingPass exists (src/passes/TypeGeneralizing.cpp)
but is registered via registerTestPass("experimental-type-generalizing", "generalize types (not yet sound)", ...) in src/passes/pass.cpp:626.
It is not part of any -O pipeline and cannot be invoked by name at the
CLI. Since the pass is explicitly not sound, using it as a comparator
would confound the code-size delta with failures on modules it touches.

2. There is no suitable GC-heavy corpus locally. The 67 lit tests
under test/lit/passes/*gc*.wast are small enough that process startup
dominates the timing. The .wasm files on this machine (CUDA
sqlite3.wasm, tree-sitter parsers) do not use GC constructs.

Given both blockers, the A/B measurement I proposed earlier cannot be
produced without more setup. Three possible directions:

A. Per-consumer --skip-pass sweep. The flag works
(--skip-pass=merge-similar-functions runs clean). For each of the
13 precision consumers, compare -O3 against -O3 --skip-pass=<consumer>
on the lit corpus. Honest data, but narrower than the original proposal:
it shows which individual consumers are net-positive or net-negative
in code size, not whether precision as a whole pays for itself.

B. Finish TypeGeneralizing's soundness. If a sound generalizer is
on the roadmap anyway, making it sound is the prerequisite for the
intended measurement. Larger; likely its own issue.

C. Accept the status quo as the answer. Per-case fixes (#9126 is the
latest) continue as the policy. If no user has reported a systematic
optimization loss, the absence of evidence may itself be the answer.

Which would you prefer? I can run A if useful, but wanted to
check whether it is the right measurement given the blockers.

This is a very broad and very verbose issue, but I don't see the background.

What is your motivation for posting it? I mean, why do you want to make progress on this? Did you find a problem somewhere?

@kripken

@kripken. Looked into the trade-off measurement before spending more
time on a benchmark. Two blockers, both worth flagging.

1. There is no sound early-generalizing pass to compare against.

createTypeGeneralizingPass exists (src/passes/TypeGeneralizing.cpp,
added in PR #6080) but is registered via registerTestPass( "experimental-type-generalizing", "generalize types (not yet sound)", ...) in src/passes/pass.cpp:626. It is not part of any -O
pipeline and cannot be invoked by name at the CLI. The pass was
explicitly marked "not yet sound" in the original PR description:

"Unlike refining cast inputs, generalizing cast outputs can break
module validation."

That is the blocking issue. Using it as a comparator would confound
the code-size delta with validation failures on the modules it touches.
--type-generalizing is not a valid flag; --experimental-type-generalizing
also fails (test passes require a build-level opt-in).

2. There is no suitable GC-heavy corpus locally.

The 67 lit tests under test/lit/passes/*gc*.wast are small enough
that process startup dominates the timing. The .wasm files on this
machine (CUDA sqlite3.wasm, tree-sitter parsers) do not use GC
constructs. A meaningful measurement needs either a real GC-heavy
module or a synthetic corpus large enough for the passes to have work
to do.

What we do know about the trade-off:

The 13 passes that consume exact types are:

src/passes/AbstractTypeRefining.cpp
src/passes/ConstantFieldPropagation.cpp
src/passes/GlobalEffects.cpp
src/passes/GlobalStructInference.cpp
src/passes/GlobalTypeOptimization.cpp
src/passes/MakeSharedObjects.cpp
src/passes/OptimizeInstructions.cpp
src/passes/Print.cpp
src/passes/RemoveUnusedBrs.cpp
src/passes/TypeMerging.cpp
src/passes/TypeRefining.cpp
src/passes/TypeSSA.cpp
src/passes/Unsubtyping.cpp

The #9126 case shows the inhibition mechanism is not a
type-comparison predicate inside a pass. It is a public-type
validity check: MergeSimilarFunctions skips merging when the call
target would become public with a type that public validation rejects
(e.g. exact references without custom descriptors). The cost of
precision is therefore at the public boundary, not inside the
pass's reasoning.

This matches the broader picture in #6965: the --closed-world flag
currently restricts what types are allowed to be public specifically
to avoid inhibiting optimizations. As @tlively wrote there:

"I believe the original motivation for these additional
restrictions was that we wanted to be able to optimize as many types
as possible, so we didn't want to allow users to expose types in a
way that would inhibit optimizations. But this is putting the cart
before the horse."

Given both blockers, the A/B measurement I proposed earlier cannot be
produced without more setup. Three possible directions:

A. Per-consumer --skip-pass sweep. The flag works
(--skip-pass=merge-similar-functions runs clean). For each of the
13 consumers, compare -O3 against -O3 --skip-pass=<consumer> on
the lit corpus. This does not answer "is precision worth it" — it
shows which individual consumers are net-positive or net-negative in
code size. It is honest data, but weaker than the original proposal.

B. Finish TypeGeneralizing's soundness. The pass was added in
#6080 with the intent to "eventually weaken casts by generalizing
(i.e. un-refining) their output types." Work continued on it through
#6118 and #6108 . If a sound generalizer is on the roadmap anyway, making it sound is the
prerequisite for the intended measurement. Larger; likely its own
issue.

C. Accept the status quo as the answer. Per-case fixes (#9126 is
the latest) continue as the policy. If no user has reported a
systematic optimization loss, the absence of evidence may itself be
the answer: the trade-off is fine at current scale.

Navigation Menu

Repository navigation

Exact Type Precision vs Optimization Cost #9133

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Exact Type Precision vs Optimization Cost #9133

Description

Activity

ArkadySkv commented on Oct 8, 2026

kripken commented on Oct 8, 2026

ArkadySkv commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions