similar to: [LLVMdev] [RFC] WebAssembly Backend

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

Dan Gohman <sunfish at mozilla.com> writes: >> Sorry, I meant why that didn't work with ELF (or what else didn't). >> > > The standard executable WebAssembly format does not use ELF, for numerous > reasons, most visibly that ELF is designed for sparse decoding -- headers > contain offsets to arbitrary points in the file, while WebAssembly's format > is

> On Jun 22, 2015, at 9:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > This part is scary. > > Having a third party library dependency is very undesirable from a testing perspective. > > I agree, but it’s what we are stuck with for now. It’s an optional dependency now, so most people building LLVM won’t need to worry about it > > One of

Hi Dan, Sure. That said I think people are just doing it anyhow :) On Wed, Sep 19, 2018 at 3:59 PM Dan Gohman <sunfish at mozilla.com> wrote: > Hi Eric, > > We've been waiting until we stabilize various key interfaces, including > the builtin functions, the C ABI, and the .o file format., as we'd like to > avoid having users using packaged versions of LLVM producing

All, I'm needing volunteers to help moderate the sessions of the LLVM Developers' Meeting. All you need to do is introduce the speaker, make sure the speaker stays on time, and run Q&A at the end (run a microphone, select people, etc). Its a pretty easy job, but critical for our meeting to run smoothly. If you are interested in moderating, please send me your top 2 session choices.

On Mon, Jul 10, 2017 at 4:13 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry for the belated response. I was on vacation last week. A couple of > thoughts on this patch and the story of webassembly linking. And I'm about to be on (mostly) vacation for next 3 weeks :) > > - This patch adds a wasm support as yet another major architecture besides >

Hi All, WebAssembly has been around for a while now, it's still being actively worked on and used. I think it's long past time we make it a normal target so that it gets tested on a regular basis. (Most recent random breakage is https://reviews.llvm.org/rL342576 which fails make check with web assembly enabled). Any objections? I'll probably do this next week unless someone raises a

Hi all, Virtual ISAs such as WebAssembly and NVPTX use infinite virtual register sets instead of traditional phsyical registers. PrologEpilogInserter is run after register allocation and asserts that all virtuals have been allocated but doesn't otherwise depend on this if scavenging is not needed. We'd like to use the target-independent PEI code for WebAssembly, so we're proposing a

Hello. Excuse me. Why CMakeLists.txt from llvm-3.9.1.src does not contain WebAssembly target? So, it is like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ X86 XCore ) but not like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ Webassembly X86

Okay, so where should I send questions for WebAssembly? Is it this mailing list or a different one? I want to ask about how to compile WebAssembly modules with Clang directly, without Emscripten, for situations like what I have currently where I have a problem with generating WebAssembly and/or JavaScript glue code (I have a problem with the gen_struct_info stuff; I asked on the Emscripten

Sean Silva <chisophugis at gmail.com> writes: > On Mon, Jul 3, 2017 at 11:12 AM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Sam Clegg via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >> >> Can you elaborate on semantically what the linker is actually doing for >> >> wasm? >> > >> >

If anyone is integrating Opus audio into a web or JavaScript application, I wrote a WebAssembly Opus decoder that uses libopusfile to decode Opus files in chunks using the JavaScript Streams API. This decoder can begin decoding after receiving the Opus headers and first audio data page: https://github.com/AnthumChris/opus-stream-decoder All thoughts and contributions are welcome, and I'm

On Wed, Dec 9, 2015 at 3:02 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Derek Schuff via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Wednesday, December 9, 2015 4:31:31 PM > > Subject: [llvm-dev] Allowing virtual registers after register allocation > > > >

Has anyone attempted to compile R (probably without any OS bindings) to WebAssembly / Emscripten? If so, how far did you get? (would be crazy awesome if you could get all the way to a ggplot bitmap output). If not, is this a waste of time or is there some daylight to doing this? [[alternative HTML version deleted]]

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

> On Dec 9, 2015, at 4:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi, > > I would actually go the other direction, i.e., stick to physical registers but with an infinite number. > The rational is that after register allocation we broke all the nice properties of the pre-alloc virtual registers. For instance, the existing liveness algorithm cannot be used

We had some additional discussion on this. There is a lot of concern generally about post-RA passes which do not expect to have to handle virtual registers; specifically if they unexpectedly start seeing virtual registers, or if they work today but start making assumptions in the future. We discussed considering a mechanism that would require MachineFunctionPasses to "opt-in" and declare

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,

As I recall, the major blocker is that R links against a number of other things (notably BLAS, pcre, etc) so while technically possible (?) I suppose, the universe of things you'd have to compile over and then get working is much larger than just the R internals. I think most people who consider this (including me years ago, as well as the poster of Gabor's message to rdevel) hit that

Hi llvmers, As you may know, work has been progressing on the experimental WebAssembly backend in llvm. However, there is currently not a good linking story. Most the of existing linking strategies (i.e. those in the emscripten toolchain) involve bitcode linking and whole program compilation at link time. To improve this situation I've been working on adding a wasm backend for lld. My