Aarav Dayal (Dec 01 2025 at 16:08): Aarav Dayal (Dec 01 2025 at 16:08):I am working on a VM for my own blockchain and would like to know if there is any workaround or way to somehow use LLVM for AoT compilation of WASM binaries.
The reason I want to do this is so that I can use wasmtime and benefit from it being up to date with the latest wasm 3.0 spec and an active ecosystem etc. while using cranelift for dev builds and llvm for much more optimized AoT builds.
Pat Hickey (Dec 01 2025 at 17:01):there is no support for using llvm as a backend in the wasmtime project, and its reasonable to expect that there never will be. wasmtime are designed for running untrusted wasm, and llvm is not designed to accept untrusted inputs.
Aarav Dayal (Dec 01 2025 at 17:07):Pat Hickey said:
there is no support for using llvm as a backend in the wasmtime project, and its reasonable to expect that there never will be. wasmtime are designed for running untrusted wasm, and llvm is not designed to accept untrusted inputs.
Wait what really? Why so? (The LLVM untrusted inputs part.)
Aarav Dayal (Dec 01 2025 at 17:09):How does wasmer deal with this? Or other wasm runtimes that support LLVM as a backend.
Alex Crichton (Dec 01 2025 at 17:09):The general expectation right now is that you'd use LLVM to compile-to-wasm which does all the necessary high-level optimizations that Cranelift won't do like auto-vectorization, loop rotations, etc. Cranelift is then a high-quality code generator which means that the <src> -> LLVM -> <wasm> -> Cranelift -> <asm> chain is still quite well optimized. Our experience is that tight loops are on-par with other WebAssembly compilers in terms of performance. In that sense while Cranelift is not as optimized of a code generator as LLVM it's expected that the lion's share of performance is still gained.
Wait what really? Why so? (The LLVM untrusted inputs part.)
LLVM is not written or architected to compile untrusted inputs. It's not really supposed to be since it's tasked with being a suitable compiler for first-party-sourced code. Compiling untrusted inputs (like what Wasmtime/WebAssembly are) is an entirely different problem. The expectation is "garbage in garbage out" with LLVM.
An example of this is that a miscompile in LLVM is not a CVE. Every single miscompile, however, has the possibility of being a CVE in the context of compiling untrusted code. LLVM maintainers (rightfully) are not reviewing all commits for evaluating the imapct of bug fixes and changes. Such behavior is required in the space of compiling untrusted inputs, however.
Alex Crichton (Dec 01 2025 at 17:10):As far as we are aware no other WebAssembly runtime using LLVM deals with this. They're either unaware of the consequences of using LLVM or choose to ignore it.
Alex Crichton (Dec 01 2025 at 17:11):You can read up on LLVM's security policy here, notably:
For example, a maliciously crafted C, Rust or bitcode input file can cause arbitrary code to execute in LLVM
And this is NOT considered a security issue in LLVM since LLVM explicitly does not provide this guarantee
Aarav Dayal (Dec 01 2025 at 17:11):Oh wow damn. I didn't know this.
Is Cranelift the most optimized right now?
Alex Crichton (Dec 01 2025 at 17:12):For Wasmtime, yes.
Aarav Dayal (Dec 01 2025 at 17:12):What do you mean?
Alex Crichton (Dec 01 2025 at 17:12):Cranelift is Wasmtime's most optimized code generator
Aarav Dayal (Dec 01 2025 at 17:13):Are there better code generators which give the best runtime performance as in my usecase startup times are a lesser priority over runtime performance.
Aarav Dayal (Dec 01 2025 at 17:13):Like not specific to wasmtime.
Aarav Dayal (Dec 01 2025 at 17:13):I am stilling exploring options to commit to a runtime.
Aarav Dayal (Dec 01 2025 at 17:13):wasmtime seems to be the best bet because of the strong backing by huge corporations.
Alex Crichton (Dec 01 2025 at 17:13):That you'll have to evaluate for yourself, I at least do not personally keep tabs on other runtimes.
Aarav Dayal (Dec 01 2025 at 17:15):Yeah I mean I just wanted to suggest that like someone at BCA should probably release benchmarks with every major release comparing wasmtime with other runtimes.
Really helps because I don't know what all kind of workloads to test the runtime on to properly compare two runtimes or whether I am even testing the runtimes on the right thing in the first place.
Chris Fallin (Dec 01 2025 at 17:38):Yeah I mean I just wanted to suggest that like someone at BCA should probably release benchmarks with every major release comparing wasmtime with other runtimes.
Please feel free to do so and post results here -- in the spirit of open source, "be the change you want to see" etc etc. As-is we don't have a benchmarking team ready to go (we're all quite busy).
If you do a modest amount of Internet searching, you'll find various comparisons people have done. Frank Denis has a round of benchmarks of a bunch of major engines that showed Wasmtime+Cranelift comparing well to LLVM-based engines. On cranelift.dev we link a paper that has detailed data as well.
Ralph (Dec 01 2025 at 19:40):moreover, to be useful the benchmarking would need to be largely agreed upon across the runtime ecosystem, and as each runtime is optimized for certain scenarios that were originally important to them, that agreement is unlikely to come. you, however, are free to help out others in your position by doing something about that. :-)
Last updated: Dec 06 2025 at 05:03 UTC