Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#9,237 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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日 22時間
マージ済み PR（30日）
97

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WebAssembly/binaryen のほかの issue

WebAssembly/binaryen の issue をすべて見る

似ている issue

Compilers の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。