[LLVMdev] [RFC] WebAssembly Backend

[Dan Gohman]

On Fri, Jun 19, 2015 at 2:57 PM, Stephen Cross <scross at scross.co.uk> wrote:
> Hi,
>
> I've read the documentation (looks very interesting!) and have some
> questions; apologies if these are answered elsewhere.
>
>> That's implementation dependent. Initially, a polyfill to JavaScript because
>> that's what exists today. We'll also implement a reference interpreter to
>> validate the spec. Each browser can do what it wants to have fast and secure
>> native support.
>
> Is there likely to be a desire at some point to produce an LLVM
> frontend (i.e. to convert from WebAssembly to LLVM IR), for example
> for compiling WebAssembly to native binaries? Furthermore, does it
> seem likely that any of the browsers would use LLVM on the client side
> for optimisation or JIT execution? Based on the comparison against
> LLVM IR, I assume the model is to use WebAssembly as a portable means
> of communicating programs but LLVM IR (or some other IR) for
> performing optimisations and other transformations (reminds me of this
> discussion: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html
> ).

Yes, it is likely someone will have this desire at some point. Such an
effort would be an entirely separate project from this WebAssembly
backend project though. To put things in perspective though,
WebAssembly is lower-level than LLVM IR. Round-tripping from LLVM IR
down to WebAssembly and back to LLVM IR would be lossy.

>
> I'm also wondering about the C ABI for WebAssembly. It sounds like
> this currently isn't specified because dynamic linking isn't supported
> yet, but presumably front-ends should be working on some kind of
> placeholder standard to avoid later incompatibility? And won't the Web
> APIs need to have some sort of ABI?

In the MVP, WebAssembly won't be able to talk to the Web APIs
directly, and applications will include a layer of JS which the
WebAssembly code can call into to do the work for it, similar to how
asm.js works today. In the future, the plan is for that layer to
become unnecessary. ABIs will be very important -- so important, that
we want to avoid getting stuck too early :-).

> I noticed the C and C++ page says pointers are 32-bits, but there will
> also ultimately be a 64-bit variant. Is there any reason to not just
> start off with 64-bit sized pointers and initially restrict usage to a
> 32-bit sized range?

Requiring 64-bit pointers when only 32 bits of them are used would
waste a lot of memory, which is not a cheap commodity in some of the
environments WebAssembly is targeting.

> In the post-MVP page it mentions 128-bit vectors; why not allow
> arbitrary (fixed-size) vectors and then have these lowered in an
> appropriate way on the target?

128 bits is a good place to start, and it leaves room for adding more
things in the future.

Dan