Binaryen vs LLVM as a compiler backend

[lei-april]

I'm thinking about designing a new programming language and compiling it to wasm.

As a compiler backend, Binaryen and LLVM are both capable of converting some IR to wasm, but I'm not sure which one to choose for my project.

I'm more familiar with LLVM and know it produces really well optimized code. On the other hand, Binaryen is used by notable projects like AssemblyScript and Grain, so I guess it should work well too.

I'd appreciate it if you could shed some light on the differences between Binaryen and LLVM as a compiler backend, like optimization capabilities, compile time, etc. Thanks!

[kripken]

I would say the big picture is:

• LLVM is much more powerful as an optimizer.
• Binaryen compiles much more quickly.
• Binaryen is much smaller.

The main factor is probably what language you are designing. If it uses GC and intends to compile to Wasm GC, then I think Binaryen is a good choice. In all other cases I think LLVM is the better choice (but it's still worth using Binaryen after LLVM runs, to further optimize the wasm output by ~15%). Specific issues are:

• LLVM does not support Wasm GC, and the future there is unclear. In general, GC is not a main focus for LLVM (almost all the languages using it use linear memory, like C, C++, Rust, Swift, Zig, etc.).
• LLVM supports wasm object files, DWARF, and other things which are very useful in the non-GC world (they may also help in GC in the future, that's unclear; we'll add support to Binaryen as needed).

[lei-april]

Thanks for your reply :)

Yes, I'm designing a language with GC. But it's targeting wasm 1.0, so GC support from the VM is not an option. It probably need a GC runtime and use the linear memory instead. In that case, do you still recommend Binaryen?

[kripken]

If you think you may want Wasm GC support eventually (even if you start with Wasm MVP for now), then I'd still recommend Binaryen, yes - to not prevent that from being an option later. It will make a big difference in performance. (And we will be able to compile Wasm GC to Wasm MVP, as a polyfill until Wasm GC is everywhere, but not the opposite.)

[trusktr]

How does it compare nowadays 2 years later?

If we'd like to make a language that compiles to both native and Wasm, what would you recommend and how would Binaryen fit in?

[kripken]

The main update compared to 2 years ago is that Binaryen now has a mature Wasm GC implementation, which is showing good results on the main Wasm GC toolchains in progress (for Java, Dart, Kotlin). Some docs on the advanced optimizations are in the wiki: https://github.com/WebAssembly/binaryen/wiki/GC-Optimization-Guidebook

Overall I'd have the same recommendations as before: Binaryen is smaller and faster, but LLVM is much more powerful. And only Binaryen supports Wasm GC.

If you want to target both Wasm and native there are some options. For LLVM you'd use the Wasm or native backend. For Binaryen you're emitting Wasm so you'd need a way to AOT-compile that Wasm to get a native binary, which some VMs can do, including V8, WAMR, CraneLift, etc.

[trusktr]

Nice, thanks for an intro on that. Suppose you are making your own new language, that will support both Wasm and native; an alternative to C/C++/Rust in which people today can write systems code, embedded, native apps, or web apps.

Is there a particular method you specifically would pick for your language (LLVM, vs, say, Wasm+CraneLift, or Wasm+wasm2c+LLVM)?

One assumption to make with this language is you would want to provide a synchronous when-out-of-scope garbage collector that is strictly good for realtime operating systems with repeatable performance timing, as well as an async undeterministic GC option that runs at random heuristically-determined points in time not good for realtime operating systems. Either way, the average end user of the language would not need to think of GC, and would write the same code regardless which GC they pick (the only difference in outcome being performance differences). My newb self imagines the first option may not use Wasm GC, and the second option would (yeah?). mylangc --gc=sync or mylangc --gc=async for either option, for example.

One more assumption is that you want to do the least work yourself, i.e. write less code, f.e. writing one IR output instead of writing two separate IR outputs.

Or is it too hard to tell up front, and you'd really have to experiment with the particular language you are making to see what works best? If so, is there something you'd lean towards at first?

[kripken]

If it's a systems language, then I'd focus on LLVM. For non-wasm builds that is the best way to get comparable performance to C/C++/Rust.