Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Closed world optimization of wasm modules that have function types in import/export boundary

未关闭
  • 哪里不对？
#9,237 7 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
18/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
wasm
领域
compilers

调研方向

Start from the repro in the issue: the module exports callForeignUninhabited and callForeignDevirtualized, which take function references from outside, and the bug appears when wasm-opt --closed-world --traps-never-happen --gufa runs on it. Trace how closed-world and GUFA decide which functions can reach a given type, since the wrong unreachable and devirtualized target both come from that. Done means the optimizer no longer assumes it knows every function of an externally passed signature, and the repro's call_ref sites keep their real targets. The maintainers have not yet settled the fix, so check the comments first.

由索引模型根据 Issue 内容生成。

描述

Let's say we have a module that can be optimized under closed world assumptions but we want to export some functions that the outside can invoke and pass callbacks of a specific type in. Concretely:

(module
  (type $sig1 (func (param i32 i64 f64) (result i32)))
  (type $sig2 (func (param i32 i32 i64) (result i32)))

  (func $unrelated (type $sig2) (param i32 i32 i64) (result i32)
    (i32.const 12345)
  )

  (export "getUnrelated" (func $getUnrelated))
  (func $getUnrelated (result (ref $sig2))
    (ref.func $unrelated)
  )

  ;; Takes a (ref $sig1) directly from outside and calls it.
  (export "callForeignUninhabited" (func $callForeignUninhabited))
  (func $callForeignUninhabited (param $fn (ref $sig1)) (param $a i32) (param $b i64) (param $c f64) (result i32)
    (call_ref $sig1 (local.get $a) (local.get $b) (local.get $c) (local.get $fn))
  )

  ;; Takes a (ref $sig2) directly from outside and calls it.
  (export "callForeignDevirtualized" (func $callForeignDevirtualized))
  (func $callForeignDevirtualized (param $fn (ref $sig2)) (param $a i32) (param $b i32) (param $c i64) (result i32)
    (call_ref $sig2 (local.get $a) (local.get $b) (local.get $c) (local.get $fn))
  )
)

If we compile this with

% wasm-opt -all --closed-world --traps-never-happen --gufa -Os -S repro.wat -o repro.opt.wat

we get

(module
 (type $sig2 (func (param i32 i32 i64) (result i32)))
 (type $sig1 (func (param i32 i64 f64) (result i32)))
 (type $2 (func (result (ref $sig2))))
 (type $3 (func (param (ref $sig1) i32 i64 f64) (result i32)))
 (type $4 (func (param (ref $sig2) i32 i32 i64) (result i32)))
 (elem declare func $unrelated)
 (export "getUnrelated" (func $getUnrelated))
 (export "callForeignUninhabited" (func $callForeignUninhabited))
 (export "callForeignDevirtualized" (func $callForeignDevirtualized))
 (func $unrelated (type $sig2) (param $0 i32) (param $1 i32) (param $2 i64) (result i32)
  (unreachable)
 )
 (func $getUnrelated (type $2) (result (ref $sig2))
  (ref.func $unrelated)
 )
 (func $callForeignUninhabited (type $3) (param $0 (ref $sig1)) (param $1 i32) (param $2 i64) (param $3 f64) (result i32)
  (unreachable)
 )
 (func $callForeignDevirtualized (type $4) (param $0 (ref $sig2)) (param $1 i32) (param $2 i32) (param $3 i64) (result i32)
  (i32.const 12345)
 )
)

So the call_ref may either be turned into an unreachable trap or devirtualized to the wrong target.

I would assume that even under --closed-world assumptions, if binaryen sees that outside world passes a function reference in that it may pass a function from a different module in (i.e. that binaryen cannot assume it knows all functions of said signature type).

Note: For the other way around, where we take the reference of a wasm function defined in our module and pass it to the outside world, we can annotate it with the (binaryen.js-called) annotation and that will prevent binaryen from changing the function type. Isn't there a mechanism for the reverse: An outside function enters our module and we call it?

/cc @tlively @kripken Is this expected? Is there a way around this?

主要语言
WebAssembly
星标
8.7k
派生
895
平均合并
1 天 23 小时
30 天内合并 PR
105

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

WebAssembly/binaryen 的其他 Issue

查看 WebAssembly/binaryen 的全部 Issue

相似的 Issue

更多 Compilers Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。