> > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/f9d5ed27/attachment.html>
> On Jun 18, 2015, at 6:47 AM, JF Bastien <jfb at google.com> wrote: > > 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.The NVPTX target does this with the existing register allocator by defining 800 physical registers of each type. It means you have to deal with unwanted spill code for those programs that exhaust the 800 registers. The greedy register allocator doesn’t scale too well along that axis IMO. I think you get something like O(#vregs x #colors-used) behavior. It’s really designed to handle a small, fixed number of physical registers. Matthias, Quentin: How well do the SSA-based register allocator algorithms work with infinite colors available? Thanks, /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150619/000aca1a/attachment.html>
> On Jun 19, 2015, at 7:49 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > >> On Jun 18, 2015, at 6:47 AM, JF Bastien <jfb at google.com <mailto:jfb at google.com>> wrote: >> >> 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. > > The NVPTX target does this with the existing register allocator by defining 800 physical registers of each type. It means you have to deal with unwanted spill code for those programs that exhaust the 800 registers. > > The greedy register allocator doesn’t scale too well along that axis IMO. I think you get something like O(#vregs x #colors-used) behavior. It’s really designed to handle a small, fixed number of physical registers. > > Matthias, Quentin: How well do the SSA-based register allocator algorithms work with infinite colors available?The SSA-based register allocators work in linear time of the number of instructions. Cheers, Q.> > Thanks, > /jakob-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150619/c5073bec/attachment.html>
Hi Jakob,> On Jun 19, 2015, at 7:49 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > Matthias, Quentin: How well do the SSA-based register allocator algorithms work with infinite colors available?The chordal coloring algorithm, at least, would be a perfect fit here. It finds the minimal coloring without pre-determined bound. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150619/3a9e9903/attachment.html>
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 >
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