search for: empscripten

...aven't gotten around to most of the intrinsics but I thought > it would be a good idea to start getting some feedback before going > much further. If anyone has the time and interest to check it out, the > repo is up at http://github.com/dmlap/llvm-js-backend. How does this compare to Empscripten? http://code.google.com/p/emscripten/ --Owen

Hi all, Over the past couple weeks, I've been putting together a JavaScript backend for LLVM. At this point, I believe I've got reasonable implementations for all the instructions, primitives and derived types. I haven't gotten around to most of the intrinsics but I thought it would be a good idea to start getting some feedback before going much further. If anyone has the time and

> $ llc bar.bc -filetype=obj -o bar.o > $ clang -shared -o bar.so bar.o > $ clang -use-gold-plugin foo.o bar.so -o t > > Is that correct? In particular, "lld t" should show a dependency on bar. > Any particular reason for not adding this to the plugin api? > > The result is a native .so here. My goal is to have a bitcode result. > >

...you have. I don't see where an LLVM IL library (libc in your > example) would fit. All that is needed is a stub with the functions that > will be defined in JS in the end. > bitcode "so" is supposed to have the form of: define void @printf() { ret void } ... In this case, Empscripten might want to generate such stubs based on the list of javascript functions they provide and in my case, the generation of this LL stub is a simple script based on nm, sed and llvm-as that takes native .so as the input and produces a bitcode file with stub definitions of the public symbols. This i...

On Sun, Dec 11, 2011 at 2:19 PM, Rafael Ávila de Espíndola < rafael.espindola at gmail.com> wrote: > On 08/12/11 03:56 PM, Ivan Krasin wrote: > > Hi llvm team! > > > > I'm currently working on the extended version of llvm-ld, which has an > > ability to check if all the symbols present (and fail if some symbols > > are not resolved), treat archives in