Hello all,
WebAssembly [0] its a new virtual ISA being designed to efficiently
run compiled code in web browsers and other things, starting with
C/C++, and eventually many other languages [1]. WebAssembly
distinguishes itself from other virtual ISAs with optimizations to
reduce download size and decode time, strong portability and
predictability invariants (for example, the base has no undefined
behavior in the C/C++ sense), and participation from several browser
vendors.
We're interested in developing and contributing an LLVM backend to
target this new ISA. There are many interesting technical aspects that
we’re excited to discuss with the LLVM community. Before we get
started though, we need to figure out how to do our development. Most
backends in LLVM were initially submitted in monolithic form and
developed incrementally thereafter. However, we have contributors from
multiple organizations, and a monolithic patch wouldn’t accurately
reflect the separate contributions.
Would the LLVM community be willing to let us start a new target from
scratch within the LLVM tree, following normal LLVM
incremental-development practices? The target would naturally start as
"experimental", excluded from the default build. The code organization
would look like any other backend, with everything under
lib/Target/WebAssembly except for various bits of configury that any
backend needs. We have need of the functionality provided by
SelectionDAG, MI and others, so this will pretty clearly be a backend,
rather than a specialized serialization. Also, the people leading the
project are JF Bastien and Dan Gohman, existing LLVM contributors
familiar with various relevant areas of LLVM.
Additionally, there are opportunities to refactor generic
infrastructure in LLVM to better support the needs of virtual ISAs,
including those in LLVM already and possibly more in the future.
Working in LLVM from the start would make collaboration with the rest
of the community easier.
We look forward to your feedback and questions. Thanks!
- The WebAssembly Community Group
[0] https://github.com/WebAssembly/design/blob/master/README.md
[1] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md
----- Original Message -----> From: "Dan Gohman" <dan433584 at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, June 17, 2015 11:16:21 AM > Subject: [LLVMdev] [RFC] WebAssembly Backend > > Hello all, > > WebAssembly [0] its a new virtual ISA being designed to efficiently > run compiled code in web browsers and other things, starting with > C/C++, and eventually many other languages [1]. WebAssembly > distinguishes itself from other virtual ISAs with optimizations to > reduce download size and decode time, strong portability and > predictability invariants (for example, the base has no undefined > behavior in the C/C++ sense), and participation from several browser > vendors. > > We're interested in developing and contributing an LLVM backend to > target this new ISA. There are many interesting technical aspects > that > we’re excited to discuss with the LLVM community. Before we get > started though, we need to figure out how to do our development. Most > backends in LLVM were initially submitted in monolithic form and > developed incrementally thereafter. However, we have contributors > from > multiple organizations, and a monolithic patch wouldn’t accurately > reflect the separate contributions. > > Would the LLVM community be willing to let us start a new target from > scratch within the LLVM tree, following normal LLVM > incremental-development practices? The target would naturally start > as > "experimental", excluded from the default build. The code > organization > would look like any other backend, with everything under > lib/Target/WebAssembly except for various bits of configury that any > backend needs. We have need of the functionality provided by > SelectionDAG, MI and others, so this will pretty clearly be a > backend, > rather than a specialized serialization. Also, the people leading the > project are JF Bastien and Dan Gohman, existing LLVM contributors > familiar with various relevant areas of LLVM. > > Additionally, there are opportunities to refactor generic > infrastructure in LLVM to better support the needs of virtual ISAs, > including those in LLVM already and possibly more in the future. > Working in LLVM from the start would make collaboration with the rest > of the community easier.I agree, developing the backend in tree is the best path. Specifically, it is the best way for the community to monitor the development and ensure proper test coverage. Obviously, there are some number of files needed for a backend to be minimally functional, and I think that putting those together and submitting them for review as a new experimental backend is perfectly appropriate. -Hal> > We look forward to your feedback and questions. Thanks! > > - The WebAssembly Community Group > > [0] https://github.com/WebAssembly/design/blob/master/README.md > [1] > https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Wed, Jun 17, 2015 at 12:24 PM Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Dan Gohman" <dan433584 at gmail.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Wednesday, June 17, 2015 11:16:21 AM > > Subject: [LLVMdev] [RFC] WebAssembly Backend > > > > Hello all, > > > > WebAssembly [0] its a new virtual ISA being designed to efficiently > > run compiled code in web browsers and other things, starting with > > C/C++, and eventually many other languages [1]. WebAssembly > > distinguishes itself from other virtual ISAs with optimizations to > > reduce download size and decode time, strong portability and > > predictability invariants (for example, the base has no undefined > > behavior in the C/C++ sense), and participation from several browser > > vendors. > > > > We're interested in developing and contributing an LLVM backend to > > target this new ISA. There are many interesting technical aspects > > that > > we’re excited to discuss with the LLVM community. Before we get > > started though, we need to figure out how to do our development. Most > > backends in LLVM were initially submitted in monolithic form and > > developed incrementally thereafter. However, we have contributors > > from > > multiple organizations, and a monolithic patch wouldn’t accurately > > reflect the separate contributions. > > > > Would the LLVM community be willing to let us start a new target from > > scratch within the LLVM tree, following normal LLVM > > incremental-development practices? The target would naturally start > > as > > "experimental", excluded from the default build. The code > > organization > > would look like any other backend, with everything under > > lib/Target/WebAssembly except for various bits of configury that any > > backend needs. We have need of the functionality provided by > > SelectionDAG, MI and others, so this will pretty clearly be a > > backend, > > rather than a specialized serialization. Also, the people leading the > > project are JF Bastien and Dan Gohman, existing LLVM contributors > > familiar with various relevant areas of LLVM. > > > > Additionally, there are opportunities to refactor generic > > infrastructure in LLVM to better support the needs of virtual ISAs, > > including those in LLVM already and possibly more in the future. > > Working in LLVM from the start would make collaboration with the rest > > of the community easier. > > I agree, developing the backend in tree is the best path. Specifically, it > is the best way for the community to monitor the development and ensure > proper test coverage. Obviously, there are some number of files needed for > a backend to be minimally functional, and I think that putting those > together and submitting them for review as a new experimental backend is > perfectly appropriate. >FWIW, I agree. However, I also suggested this approach, so I'm probably biased. ;] I just wanted to explicitly say that I think this is a great path forward and I'm cautiously optimistic about the entire effort.> > -Hal > > > > > We look forward to your feedback and questions. Thanks! > > > > - The WebAssembly Community Group > > > > [0] https://github.com/WebAssembly/design/blob/master/README.md > > [1] > > https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/ab9761b7/attachment.html>
On Jun 17, 2015, at 9:16 AM, Dan Gohman <dan433584 at gmail.com> wrote:> Would the LLVM community be willing to let us start a new target from > scratch within the LLVM tree, following normal LLVM > incremental-development practices? The target would naturally start as > "experimental", excluded from the default build. The code organization > would look like any other backend, with everything under > lib/Target/WebAssembly except for various bits of configury that any > backend needs. We have need of the functionality provided by > SelectionDAG, MI and others, so this will pretty clearly be a backend, > rather than a specialized serialization. Also, the people leading the > project are JF Bastien and Dan Gohman, existing LLVM contributors > familiar with various relevant areas of LLVM.Sounds great to me, -Chris
On 06/17/2015 09:16 AM, Dan Gohman wrote:> Would the LLVM community be willing to let us start a new target from > scratch within the LLVM tree, following normal LLVM > incremental-development practices? The target would naturally start as > "experimental", excluded from the default build. The code organization > would look like any other backend, with everything under > lib/Target/WebAssembly except for various bits of configury that any > backend needs. We have need of the functionality provided by > SelectionDAG, MI and others, so this will pretty clearly be a backend, > rather than a specialized serialization. Also, the people leading the > project are JF Bastien and Dan Gohman, existing LLVM contributors > familiar with various relevant areas of LLVM.+1. I see no real downside to this proposal.> Additionally, there are opportunities to refactor generic > infrastructure in LLVM to better support the needs of virtual ISAs, > including those in LLVM already and possibly more in the future. > Working in LLVM from the start would make collaboration with the rest > of the community easier.Can you list some of the areas you know are going to need attention? What problems are you seeing? (It might be best to move this to it's own thread or keep this very high level for now.) Philip
On Wed, Jun 17, 2015 at 4:12 PM, Philip Reames <listmail at philipreames.com> wrote:> On 06/17/2015 09:16 AM, Dan Gohman wrote: >> Additionally, there are opportunities to refactor generic >> infrastructure in LLVM to better support the needs of virtual ISAs, >> including those in LLVM already and possibly more in the future. >> Working in LLVM from the start would make collaboration with the rest >> of the community easier. > > Can you list some of the areas you know are going to need attention? What > problems are you seeing? (It might be best to move this to it's own thread > or keep this very high level for now.)We'll definitely be starting separate threads when we're ready, but briefly, one of the things we'll need to look into is MC. Right now, MC's interfaces appear to be tailored for native-binary-style encodings, so if we're going to use MC, it'll likely need some refactoring to generalize it. Dan
On Wed, Jun 17, 2015 at 09:16:21AM -0700, Dan Gohman wrote:> Hello all, > > WebAssembly [0] its a new virtual ISA being designed to efficiently > run compiled code in web browsers and other things, starting with > C/C++, and eventually many other languages [1]. WebAssembly > distinguishes itself from other virtual ISAs with optimizations to > reduce download size and decode time, strong portability and > predictability invariants (for example, the base has no undefined > behavior in the C/C++ sense), and participation from several browser > vendors. > > We're interested in developing and contributing an LLVM backend to > target this new ISA. There are many interesting technical aspects that > we’re excited to discuss with the LLVM community. Before we get > started though, we need to figure out how to do our development. Most > backends in LLVM were initially submitted in monolithic form and > developed incrementally thereafter. However, we have contributors from > multiple organizations, and a monolithic patch wouldn’t accurately > reflect the separate contributions. >> Would the LLVM community be willing to let us start a new target from > scratch within the LLVM tree, following normal LLVM > incremental-development practices? The target would naturally start as > "experimental", excluded from the default build. The code organization > would look like any other backend, with everything under > lib/Target/WebAssembly except for various bits of configury that any > backend needs. We have need of the functionality provided by > SelectionDAG, MI and others, so this will pretty clearly be a backend, > rather than a specialized serialization. Also, the people leading the > project are JF Bastien and Dan Gohman, existing LLVM contributors > familiar with various relevant areas of LLVM. > > Additionally, there are opportunities to refactor generic > infrastructure in LLVM to better support the needs of virtual ISAs, > including those in LLVM already and possibly more in the future. > Working in LLVM from the start would make collaboration with the rest > of the community easier. > > We look forward to your feedback and questions. Thanks! >Hi, 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? How will the ISA be transformed to machine code? Why do you want to develop a full backend as opposed to a simple LLVM IR translation pass that converts IR directly to WebAssembly? -Tom> - The WebAssembly Community Group > > [0] https://github.com/WebAssembly/design/blob/master/README.md > [1] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > 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 Wed, Jun 17, 2015 at 12:20 PM, Hal Finkel <hfinkel at anl.gov> wrote:> I agree, developing the backend in tree is the best path. Specifically, it is the best way for the community to monitor the development and ensure proper test coverage. Obviously, there are some number of files needed for a backend to be minimally functional, and I think that putting those together and submitting them for review as a new experimental backend is perfectly appropriate.For people following this thread, I've now posted such a patch here: http://reviews.llvm.org/D10569 Dan