[LLVMdev] [RFC] WebAssembly Backend

[Stephen Cross]

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
).

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?

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?

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?

Thanks,
Stephen

On Thu, Jun 18, 2015 at 2:47 PM, JF Bastien <jfb at google.com> wrote:
>> This seems interesting, I have a few questions:
>>
>>
>> Has the ISA been finalized yet or is it still a work in progress?  Will
>> there be a fixed number of registers?
>
>
> The design document has a high-level idea of the ISA, or rather of the AST
> we're thinking of going with:
>
> https://github.com/WebAssembly/design/blob/master/AstSemantics.md
>
> The final encoding isn't decided on, we're still missing experiments to
> figure out precise details.
>
> We foresee having an infinite number of locals per function, but we plan to
> pre-color them so that locals whose lifetimes don't interfere can be merged.
> We can get clever and do this in an interesting order.
>
>
>> How will the ISA be transformed to machine code?
>
>
> 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.
>
>
>> Why do you want to develop a full backend as opposed to a simple LLVM
>> IR translation pass that converts IR directly to WebAssembly?
>
>
> Because that's proven to have unfortunate shortcomings in both PNaCl and
> Emscripten. Doing a true backend has significant advantages including in
> amount of code needed, and in what e.g. ISel can do for us for legalization
> and clever instruction selection.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>