wasm-builder uses hacks to build WASMs

[StackOverflowExcept1on]

Problem

Starting with Rust 1.82 WASMs contain multi-value and reference-types features: https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features.html. However, Rust does not currently even provide support for multi-value and reference-types in language.

We currently use hack #4247 to solve this issue. This hack results in end user having to:

• install rust-src component for building smart contracts
• -Zbuild-std increases build time (while wasm-builder itself is slow)
• removing -Clinker-plugin-lto increases binary sizes (it was removed because I found some bug in Rust/LLVM: Can not disable reference-types feature for wasm32 target with -C linker-plugin-lto flag rust-lang/rust#130604)), compiler also cannot delete panic locations
• RUSTC_BOOTSTRAP=1 reduces stability since the user may be using nightly features in WASMs

Other optimization/parsing/executions issues:

• wasmer signlepass does not support multi-value (https://docs.wasmer.io/runtime/features#support-of-features-by-backend)
• wasm-opt does not support multi-value (Support block-type parameters WebAssembly/binaryen#6407)
• parity-wasm fork does not support reference-types
• parity-wasm-instrument fork does not support reference-types (stack height instrumentation and gas charge for new instructions)

Steps

No response

Possible Solution

• Update wasmi and wasmer executor
• Support multi-value and reference-types parsing in our parity-wasm fork
  • chore: enable multi-value without feature parity-wasm#4
  • TODO: reference-types
• Support multi-value and reference-types in parity-wasm-instrument
  • feat(stack-limiter): support multi-value feature wasm-instrument#8
  • TODO: reference-types
• Benchmarks of new instructions, possibly charging gas for tables, etc.

Notes

No response

Relevant Log Output

No response

[playX18]

I was looking into Wasmtime and Wasmer in terms of supporting new features including multivalue and ref-types.

Wasmtime

Wasmtime did not have singlepass backend until recently, now they have Winch which is still Tier 4 in support aka it does not support reference-types and only can compile to x86_64 backend at the moment.
I did some local testing and while it runs small programs I throw at it just fine I am unable to test it to full extent yet, probably we could try to experimentally add Winch support to Gear if we ever look into using it instead of Wasmer.

Wasmer

Wasmer does have singlepass backend but does not support multivalue which we need so much. It's possible to fork wasmer and add the code for x64 and aarch64 backends by our own efforts and then try merge that into mainstream but it's unlikely it will be prioritized by the Wasmer team (see wasmerio/wasmer#5286).
We could instead maintain our own fork and sync it with mainstream when needed.

Alternatives

One possible alternative is using something like binaryen API to implement a pass that removes multivalue usage in code and converts it to locals. There is only one cons of this approach is that it could add significant overhead to upload_code as it would require constructing internal binaryen CFG in order to perform operations on WASM code.
As @breathx pointed out in chat, we can run this pass in wasm-builder instead and just verify that multivalue does not exist in code at instrumentation phase.