Can not disable sign-ext feature for wasm32 target

[laizy]

I tried to build a wasm binary with MVP opcode only, so I disabled the features:

RUSTFLAGS='-C link-arg=-zstack-size=32768 -C target-feature=-mutable-globals,-sign-ext,-multivalue,-simd128'
 cargo build --release --target=wasm32-unknown-unknown

I expected to see no sign-extension opcode in the wasm binary.

Instead, this happened:

$ wasm-tools parse -t target/wasm32-unknown-unknown/release/output.wasm -o hello.wat
$ cat hello.wat | grep i32.ext
                            i32.extend8_s

Meta

rustc --version --verbose:

rustc 1.70.0-nightly (ec2f40c6b 2023-03-30)
binary: rustc
commit-hash: ec2f40c6b04f0e9850dd1f454e8639d319f4ed9b
commit-date: 2023-03-30
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0

Backtrace

<backtrace>

[CryZe]

You can not deactivate default features, because std is prebuilt. You need -Z build-std to build std yourself. Also these features are considered the default by LLVM ever since the recent upgrade to LLVM 16:

https://github.com/llvm/llvm-project/blob/f991f30845bb464a1a8e240b3512bac0258417db/llvm/lib/Target/WebAssembly/WebAssembly.td#L99-L106

This should possibly be mentioned in the Rust 1.70 release notes though?

[nikic]

cc @alexcrichton to confirm that we're fine with inheriting this change to default target features in Rust.

[alexcrichton]

More context for this change can be found in these locations:

• Enabling features by default in LLVM WebAssembly/tool-conventions#158 (comment) - discussion about enabling new features in both Emscripten and LLVM.
• https://reviews.llvm.org/D125728 - the original LLVM patch for this
• https://reviews.llvm.org/D125729 - more follow-up discussion on LLVM

In that sense this is an expected change, but at the same time the change was made with the expectation that most users are running on an engine that implements sign-extension. @laizy could you expand a bit more on your motivation for excluding these sign-extension instructions?

I do agree, though, that this should be mentioned in the detailed release notes. It's unfortunately a bit opaque since not all users of wasm are intimately familiar with proposals and whether or not engines support them, but it's a change nonetheless worth mentioning.

[laizy]

I have tried to use -Z build-std=core, alloc, still not work:

RUSTFLAGS="-C link-arg=-zstack-size=32768 -C target-feature=-mutable-globals,-sign-ext,-multivalue,-simd128" cargo build -Z build-std=core,alloc --release --target=wasm32-unknown-unknown

@alexcrichton Our blockchain platform has used Wasm as a virtual machine running smart contracts and has been running steadily for many years. The MVP opcodes is fully sufficient for our use case. I hope there are ways to turn off these default extension features to avoid frequent upgrades every time a new feature is introduced.

[alexcrichton]

Could you share the code used to reproduce this?

These upgrades will not be frequent. This is the first time it's changed in 5 years.

[shanemadden]

The use case I have for wanting to build without these extensions isn't critical (servers for a game which don't support the extensions in the old version of nodejs they're running), but a way to successfully disable them to be able to build for such environments would be appreciated!

[alexcrichton]

It would be helpful to have a reproduction of this to run to test out fixes. I tested something locally and -Ctarget-cpu=mvp was sufficient to disable sign extension instructions. I don't know why -C target-feature=-sign-ext isn't working and that may be an LLVM bug. I can't confirm whether this works for others though without a means of reproduction.

[CryZe]

I just tried the following:

#[no_mangle]
pub extern "C" fn foo(a: &i8, b: &i8) -> i32 {
    (*a + *b) as _
}

compiled with:
RUSTFLAGS="-C target-feature=-sign-ext" cargo build --target wasm32-unknown-unknown --release -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

to make sure std being precompiled isn't causing problems, and it totally still contains the sign-ext instructions:

(func (;0;) (type 0) (param i32 i32) (result i32)
    local.get 1
    i32.load8_u
    local.get 0
    i32.load8_u
    i32.add
    i32.extend8_s)

So you are right, this is some sort of LLVM bug.

[shanemadden]

Confirming that -Ctarget-cpu=mvp results in a file without the sign-ext opcodes, while -Ctarget-feature=-sign-ext does not, in my testing as well.

[alexcrichton]

@sunfishcode would you perhaps know more about this behavior? I would expect that with -sign-ext on the function then even without -mcpu=mvp sign-extension instructions wouldn't get generated, but I'm not sure.

[sunfishcode]

I wonder if this is a consequence of https://reviews.llvm.org/D59625. It looks like that might be unioning the module-level features along with the per-function features to form the effective feature set to use.

[kvinwang]

I just tried the following:

#[no_mangle]
pub extern "C" fn foo(a: &i8, b: &i8) -> i32 {
    (*a + *b) as _
}

compiled with: RUSTFLAGS="-C target-feature=-sign-ext" cargo build --target wasm32-unknown-unknown --release -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

to make sure std being precompiled isn't causing problems, and it totally still contains the sign-ext instructions:

(func (;0;) (type 0) (param i32 i32) (result i32)
    local.get 1
    i32.load8_u
    local.get 0
    i32.load8_u
    i32.add
    i32.extend8_s)

So you are right, this is some sort of LLVM bug.

It can also be reproduced with: RUSTFLAGS="-C linker-plugin-lto -C target-cpu=mvp" cargo build --target wasm32-unknown-unknown --release -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

[stephanemagnenat]

A slightly related issue is that the WebAssembly extensions used by default by the Rust compiler are not documented (besides in the change log, but new users won't look at it), I opened a specific issue for that (#119811) and just want to link it here.

[alexcrichton]

As a heads up I've added documentation about features to #128511 which I've currently got as flagged to close this issue. The documented solution for targetting MVP wasm is:

$ export RUSTFLAG=-Ctarget-cpu=mvp
$ cargo +nightly build -Zbuild-std=panic_abort,std --target wasm32-unknown-unknown

which should solve the original OP of this issue. Other solutions in this issue such as using -Ctarget-feature=-sign-ext or that in conjunction with -Clto or others don't work for one reason or another. Using the mvp target-cpu, however, plus recompiling the standard library with -Zbuild-std, does work.