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

OptimizeInstructions: `select (memory.grow 1) (memory.grow 1) c` is folded to one operand and returns the wrong result

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

维护者通常 1 天内回复

@tamaroning 已经在做这个了。

开始于 2026年10月7日。

  • #9227 来自 @tamaroning —— 未关闭

评估

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

调研方向

Start at the line 2893 check in OptimizeInstructions and reproduce the issue with the supplied wasm-opt commands and WebAssembly modules. Verify the fix with --optimize-instructions --fuzz-exec for the memory.grow, array.get, atomic RMW, and table.grow cases, ensuring optimized results match the originals.

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

描述

Summary

areConsecutiveInputsEqual treats two syntactically equal operands as equal in value when their children have no effects. That is wrong for operands that themselves write state (memory.grow, table.grow, atomic RMW), which return a different value on each evaluation.

Root cause

The check at line 2893, fallthroughEffects.orderedBefore(fallthroughChildEffects), leaves the operand itself out so that an idempotent call does not interfere with itself. As a result, an operand that reads and writes the same state, like memory.grow, is never compared with itself, and isGenerative (calls and allocations only) does not catch it. A possible fix is to also reject an operand whose own effects interfere with a second evaluation of itself, keeping the exemption for idempotent calls only.

Affected passes

Only OptimizeInstructions.

Reproducer
(module (memory 1 5)
  (func (export "s") (result i32)
    (select (memory.grow (i32.const 1)) (memory.grow (i32.const 1)) (i32.const 1))))

$ wasm-opt in.wat -all --optimize-instructions --print
 (func $0 (type $0) (result i32)
  (drop
   (memory.grow
    (i32.const 1)
   )
  )
  (drop
   (i32.const 1)
  )
  (memory.grow
   (i32.const 1)
  )
 )

The condition is 1, so the select must return the first grow's result:

$ wasm-opt in.wat -all --optimize-instructions --fuzz-exec -o /dev/null
[fuzz-exec] export s
[fuzz-exec] note result: s => 1
[fuzz-exec] export s
[fuzz-exec] note result: s => 2
[fuzz-exec] comparing s
values not identical! 2 != 1
[fuzz-exec] optimization passes changed results

Second reproducer:

(module
  (type $a (array (mut i32)))
  (memory 1 10)
  (func (export "f") (result i32)
    (array.get $a
      (array.new_fixed $a 2 (memory.grow (i32.const 1)) (memory.grow (i32.const 1)))
      (i32.const 1))))

$ wasm-opt in.wat --enable-reference-types --enable-gc --optimize-instructions --fuzz-exec -o /dev/null
[fuzz-exec] export f
[fuzz-exec] note result: f => 2
[fuzz-exec] export f
[fuzz-exec] note result: f => 1
[fuzz-exec] comparing f
values not identical! 1 != 2
[fuzz-exec] optimization passes changed results
Expected vs actual

select, c = 1: the original returns the first grow's result, 1; the optimized module returns 2. array.get ... 1: the original gives 2; the optimized module gives 1. Two i32.atomic.rmw.adds and table.grow behave the same.

Version

Reproduced on upstream main at 4d8ac549e2ab9b283246ea95e79ebe139ca579ac (wasm-opt version 133).

AI was used as part of the process of finding this issue. I have manually checked and reproduced it.

主要语言
WebAssembly
星标
8.7k
派生
893
平均合并
1 天 18 小时
30 天内合并 PR
95

环境准备

  • 没有 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 摘要。