[mraleph]

> but it also compiles to ARM binary via LLVM for iOS applications

[disclaimer: I am TL for Dart Native Compilers]

We currently don't use LLVM for compiling Dart to native and we actually never used it in production - though we previously built couple of prototypes to evaluate potential benefits of using LLVM.

We use our own AOT compilation toolchain which has roots in our JIT compiler for Dart.

> meaning that compiling to WASM should be a trivial option

It's not really trivial because you still need to figure out some things - most importantly GC. On ARM you can scan the stack - on WASM you can't. They are working on GC support from WASM, but I don't think it is ready yet. And some things are just unfortunate (e.g. i31ref type which mimics V8's SMI - Dart SMI's are 63-bit on 64-bit platforms).

[mikece]

I stand corrected -- is there a blog post or other deep-dive material where I could learn more?

[mraleph]

There is some information at https://mrale.ph/dartvm/ but there is nothing really comprehensive right now.

[markdog12]

I noticed Chrome Canary added a WebAssembly GC flag last week or so. SIMD too. I think FF had the GC flag for a while now.

[pingucrimson]

Out of curiosity, why'd you decide not to use LLVM?

[mraleph]

In the two experiments that we did LLVM brought only marginal benefits so we could not warrant the huge dependency and associated maintenance costs. We already have a good compilation pipeline, which was developed for the JIT mode and we use that for AOT with good results. Adding LLVM on top increases complexity - suddenly to tweak things you need to be an expert both in our compilation pipeline and LLVM (which is probably 100x larger than the whole Dart VM source code).

A lot of optimizations which benefit Dart code size and performance require high level optimizations anyway, so having LLVM does not help you in any way.

That said there are obvious benefits for having LLVM as a backend - so we are planning to explore it yet again in the near future.