wasmtime / issue #11045 Cranelift: Unexpected negative op... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #11045 Cranelift: Unexpected negative op...

Wasmtime GitHub notifications bot (Jun 14 2025 at 13:10):

OwenWangbattle added the bug label to Issue #11045.

Wasmtime GitHub notifications bot (Jun 14 2025 at 13:10):

OwenWangbattle opened issue #11045:

evalloop.c

The full code is in https://github.com/llvm/llvm-test-suite/blob/main/SingleSource/Benchmarks/Misc/evalloop.c

Compile Command

emcc -O0/-O3 -s WASM=1 -s TOTAL_MEMORY=512MB evalloop.c -o evalloop.wasm wasmtime compile -C compiler=cranelift -O opt-level=2 evalloop.wasm -o evalloop.cwasm

Run Command

wasmtime --wasm max-wasm-stack=8388608 --allow-precompiled evalloop.cwasm

Results

I ran the program 10 times and got the average execution time.
Time for O3 optimization flag: 2.43s
Time for O0 optimization flag: 0.81s
Time for Wasmer LLVM Compiler AOT: 1.09s

Versions and Environment

Cranelift version or commit: wasmtime-cli 22.0.0 (761f044ef 2024-06-20)

Operating system: Ubuntu 22.04.5 LTS(Linux)

Architecture: x86_64

CPU: Intel(R) Xeon(R) Gold 5218R CPU @ 2.10GHz

Extra Info

I think there may be some negative optimization for the pattern that calling function in the switch structure.

Wasmtime GitHub notifications bot (Jun 14 2025 at 13:10):

OwenWangbattle added the cranelift label to Issue #11045.

Wasmtime GitHub notifications bot (Jun 14 2025 at 13:12):

OwenWangbattle commented on issue #11045:

Sorry, the Compile Command is
emcc -O0/-O3 -s WASM=1 -s TOTAL_MEMORY=512MB evalloop.c -o evalloop.wasm
wasmtime compile -C compiler=cranelift -O opt-level=2 evalloop.wasm -o evalloop.cwasm

Wasmtime GitHub notifications bot (Jun 15 2025 at 16:57):

alexcrichton edited issue #11045:

evalloop.c

The full code is in https://github.com/llvm/llvm-test-suite/blob/main/SingleSource/Benchmarks/Misc/evalloop.c

Compile Command

emcc -O0/-O3 -s WASM=1 -s TOTAL_MEMORY=512MB evalloop.c -o evalloop.wasm wasmtime compile -C compiler=cranelift -O opt-level=2 evalloop.wasm -o evalloop.cwasm

Run Command

wasmtime --wasm max-wasm-stack=8388608 --allow-precompiled evalloop.cwasm

Results

I ran the program 10 times and got the average execution time.
Time for O3 optimization flag: 2.43s
Time for O0 optimization flag: 0.81s
Time for Wasmer LLVM Compiler AOT: 1.09s

Versions and Environment

Cranelift version or commit: wasmtime-cli 22.0.0 (761f044ef 2024-06-20)

Operating system: Ubuntu 22.04.5 LTS(Linux)

Architecture: x86_64

CPU: Intel(R) Xeon(R) Gold 5218R CPU @ 2.10GHz

Extra Info

I think there may be some negative optimization for the pattern that calling function in the switch structure.

Wasmtime GitHub notifications bot (Jun 15 2025 at 17:03):

alexcrichton commented on issue #11045:

Originally the link in the issue pointed to url so I updated it to point to the file that the text of the link was showing, but just wanted to confirm -- if you follow that link is that the test you're interested in?

This may be a producer toolchain issue rather than a Wasmtime issue as well. The emcc compiler I believe by default runs wasm-opt which means that you're dealing with both the LLVM and wasm-opt optimization pipeline. I'd recommend narrowing this down further to figure out what optimization is causing the slowdown vs not as that will make this much easier to debug.

I used a small script:
for i in 0 1 2 3; do
  $WASI_SDK_PATH/bin/clang foo.c -o o$i.wasm -O$i
  wasmtime compile o$i.wasm
  echo "O$i"
  time wasmtime run --allow-precompiled o$i.cwasm
done
which uses just wasi-sdk which is just LLVM, not wasm-opt, and I get:
O0
Sum: 3273600000

real    0m0.546s
user    0m0.544s
sys     0m0.006s
O1
Sum: 3273600000

real    0m0.306s
user    0m0.301s
sys     0m0.006s
O2
Sum: 3273600000

real    0m0.317s
user    0m0.320s
sys     0m0.003s
O3
Sum: 3273600000

real    0m0.308s
user    0m0.305s
sys     0m0.006s
which looks like this doesn't show any slowdown with higher optimization levels, definitely nothing close to 2+ seconds as you're seeing.

For me though it's just a hunch that wasm-opt might be doing something here, I don't actually have either emcc or wasm-opt installed locally. Can you @OwenWangbattle work on debugging this more? Can you reproduce with just wasi-sdk? Can you disable wasm-opt (I'm not sure how to do this) with emcc and see if that's causing the issue? If so this might be an issue best for Binaryen rather than Wasmtime.

Wasmtime GitHub notifications bot (Jun 17 2025 at 06:14):

OwenWangbattle commented on issue #11045:

Originally the link in the issue pointed to url so I updated it to point to the file that the text of the link was showing, but just wanted to confirm -- if you follow that link is that the test you're interested in?

This may be a producer toolchain issue rather than a Wasmtime issue as well. The emcc compiler I believe by default runs wasm-opt which means that you're dealing with both the LLVM and wasm-opt optimization pipeline. I'd recommend narrowing this down further to figure out what optimization is causing the slowdown vs not as that will make this much easier to debug.

I used a small script:

for i in 0 1 2 3; do $WASI_SDK_PATH/bin/clang foo.c -o o$i.wasm -O$i wasmtime compile o$i.wasm echo "O$i" time wasmtime run --allow-precompiled o$i.cwasm done

which uses just wasi-sdk which is just LLVM, not wasm-opt, and I get:

```
O0
Sum: 3273600000

real 0m0.546s
user 0m0.544s
sys 0m0.006s
O1
Sum: 3273600000

real 0m0.306s
user 0m0.301s
sys 0m0.006s
O2
Sum: 3273600000

real 0m0.317s
user 0m0.320s
sys 0m0.003s
O3
Sum: 3273600000

real 0m0.308s
user 0m0.305s
sys 0m0.006s
```

which looks like this doesn't show any slowdown with higher optimization levels, definitely nothing close to 2+ seconds as you're seeing.

For me though it's just a hunch that wasm-opt might be doing something here, I don't actually have either emcc or wasm-opt installed locally. Can you @OwenWangbattle work on debugging this more? Can you reproduce with just wasi-sdk? Can you disable wasm-opt (I'm not sure how to do this) with emcc and see if that's causing the issue? If so this might be an issue best for Binaryen rather than Wasmtime.

I investigated this case further these days. I thought you might be right. It might be caused by Binaryen instead of wasmtime.
emcc -O3 -s WASM=1 -s TOTAL_MEMORY=512MB evalloop.c -o evalloop.wasm -v to see how emscripten compiled this program to wasm module. I followed its process without the wasm-opt optimization. And I found that the execution time of the program reduced to 1.6s. If I only used wasi-sdk and clang to compile the program, the execution time for O3 optimization flag was 0.64s and for O0 was 0.86s. The result was the same as you mentioned.
Thank you for your suggestion!

Wasmtime GitHub notifications bot (Jun 17 2025 at 14:31):

alexcrichton closed issue #11045:

evalloop.c

The full code is in https://github.com/llvm/llvm-test-suite/blob/main/SingleSource/Benchmarks/Misc/evalloop.c

Compile Command

emcc -O0/-O3 -s WASM=1 -s TOTAL_MEMORY=512MB evalloop.c -o evalloop.wasm wasmtime compile -C compiler=cranelift -O opt-level=2 evalloop.wasm -o evalloop.cwasm

Run Command

wasmtime --wasm max-wasm-stack=8388608 --allow-precompiled evalloop.cwasm

Results

I ran the program 10 times and got the average execution time.
Time for O3 optimization flag: 2.43s
Time for O0 optimization flag: 0.81s
Time for Wasmer LLVM Compiler AOT: 1.09s

Versions and Environment

Cranelift version or commit: wasmtime-cli 22.0.0 (761f044ef 2024-06-20)

Operating system: Ubuntu 22.04.5 LTS(Linux)

Architecture: x86_64

CPU: Intel(R) Xeon(R) Gold 5218R CPU @ 2.10GHz

Extra Info

I think there may be some negative optimization for the pattern that calling function in the switch structure.

Wasmtime GitHub notifications bot (Jun 17 2025 at 14:31):

alexcrichton commented on issue #11045:

Ok sounds good! I'm going to close this then.

Last updated: Dec 06 2025 at 06:05 UTC