Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Exact Type Precision vs Optimization Cost

Đang mở
  • Có gì không ổn?
#9,133 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
python, wasm
Lĩnh vực
compilers, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
WebAssembly
Star
8.6k
Fork
892
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
72

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của WebAssembly/binaryen

Tất cả issue của WebAssembly/binaryen

Issue tương tự

Thêm issue về Compilers

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.