I was testing cranelift/filetests/filetests/runtests/*.clif with the riscv64 target on x86-64, and I thought the clif-util test (test run) command and the clif-util run command would produce the same result, but I noticed that their behavior is different. For example, when I tested bb-padding.clif, the test command passed, but running run resulted in an error. Could you explain why this happens?
clif-util test:
wasmtime$ qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD\_LIBRARY\_PATH=/usr/riscv64-linux-gnu/lib target/riscv64gc-unknown-linux-gnu/debug/clif-util test -v ./cranelift/filetests/filetests/runtests/bb-padding.clif
0.581 ./cranelift/filetests/filetests/runtests/bb-padding.clif
1 tests
clif-util run:
wasmtime$ qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD\_LIBRARY\_PATH=/usr/riscv64-linux-gnu/lib target/riscv64gc-unknown-linux-gnu/debug/clif-util run -v ./cranelift/filetests/filetests/runtests/bb-padding.clif
./cranelift/filetests/filetests/runtests/bb-padding.clif: Compilation error: Unsupported feature: should be implemented in ISLE: inst = `v0 = vconst.i64x2 const0`, type = `Some(types::I64X2)`
1 file
Error: 1 failure
This topic was moved here from #wasmtime > Difference between clif-util test run and clif-util run. by Till Schneidereit.
@Masashi Yoshimura I moved this over to the #cranelift channel so you'd get more Cranelift focused folks to see it
I believe this is because clif-util test reads the configuration options at the top (e.g. cranelift settings, target, etc) while clif-util run does not, so run is failing due to vector features being disabled
@Alex Crichton Thanks. Then, Is it possible to pass a setting options (e.g., has_v) to run, like with clif-util compile --set?
clif_util::compile::Options has a settings: Vec<String>, but clif_util::run::Options doesn’t. It looks like to me the setting options can’t be passed to run.
Ah sorry I'm not familiar enough with run off the top of my head to know the answer
@Masashi Yoshimura it seems that the run command is legacy from early Cranelift where it was more useful to experiment with and directly invoke machine code. We have a much more structured testing situation now, and we also have removed "dummy environments" from Cranelift in the past (e.g., clif-util wasm no longer exists). I think the right move here is actually to decide that clif-util run is unneeded, and mostly redundant given that we have runtests, and delete it
In general it's difficult to use Cranelift on its own -- we have testing functionality that effectively mirrors runtime bits that Wasmtime also implements, like trampolines and an unwinder, but overall it makes the most sense to use the library in the context of an embedder. I'd be curious what your use-case is and why you need clif-util run -- can you say more?
Thank you! I understand.
I'd be curious what your use-case is and why you need
clif-util run-- can you say more?
I was simply experimenting with Cranelift and don’t have a particular use case at the moment.
Last updated: Dec 06 2025 at 07:03 UTC