Binaryen changes type structure in open world even with zero-level optimization enabled

[igoriakovlev]

It seems passing a .wasm file could change types structure for exported tag.

I use this command to optimise attached example which originally works fine:

wasm-opt --enable-gc --enable-reference-types --enable-exception-handling --enable-bulk-memory --enable-nontrapping-float-to-int --inline-functions with-loops --traps-never-happen --fast-math stdlib.wasm -o xxx.wasm

And get this warning: no passes specified, not doing any work, but nevertheless, when I replace stdlib.wasm with xxx.wasm and reload app to use optimised .wasm file I get

LinkError: WebAssembly.instantiate(): Import #74 "stdlib" "tag_throwable": imported tag does not match the expected type
So seems binaryen rewrite exported tag type so it cannot be imported.

Reproduced on binaryen 121 and [current master]
binaryen_bug.zip

[kripken]

Here is how I tried to reproduce this:

• Unpack the second archive, binaryen_bug.zip
• python -m http.server
• View the website at localhost:8000, I see a button "Click me!" I click it and a shape drops down with text "Compose: Hello, WasmJs!". No errors in the console.
• I applied the binaryen command mentioned here, but on skiko.wasm and not stdlib.wasm that was mentioned (because I do not see stdlib.wasm anywhere), wasm-opt --enable-gc --enable-reference-types --enable-exception-handling --enable-bulk-memory --enable-nontrapping-float-to-int --inline-functions-with-loops --traps-never-happen --fast-math skiko.wasm -o skiko.wasm.
  • Note that when doing so I had to fix a typo, --inline-functions with-loops needs a - instead of the space there.
• That operation changes the wasm file by a few bytes. I then once more loaded the website, and it ran exactly as in the third bullet point here.

Should I be doing something else?

[igoriakovlev]

Hi, the archive contains stdlib.wasm. Please take a look more carefully. Without stdlib.wasm the app cannot start.
I have checked the archive and the file is there
https://github.com/user-attachments/files/18425504/binaryen_bug.zip

[tlively]

This is going to be due to the fact that we store Signature instead of HeapType on Tags. I can work on this.

[kripken]

@igoriakovlev ah, you're right, I missed that there was a second wasm file there, sorry.

[tlively]

@igoriakovlev, are you going to need a new Binaryen release once the fix lands?

[igoriakovlev]

@tlively well, this issue needed for our experiments and I can build it by myself. But it will be nice to release it anyway because of fixes of multivalued blocks. Thank you.