LLVM backend for emscripten

Showing 1-9 of 9 messages
LLVM backend for emscripten Alon Zakai 12/19/13 5:53 PM
Hello everyone,

We've experimented in the past with an LLVM backend to replace parts of emscripten, most of which is written in JS. We hit some difficulties each time, and this was deferred. However, it looks like now everything is coming together, and we are on track. Details here:

https://github.com/kripken/emscripten/wiki/LLVM-Backend

Basically, the new compiler (codename "fastcomp" in commits) is an LLVM IR-based backend, so similar to the C++ backend (and as opposed to most other backends which are SDAG/tblgen based). This will replace much of the custom LLVM IR parsing and processing code in src/*, but not replace any of

 * libraries
 * toolchain
 * js optimizer (tools/js-optimizer.js)

The idea is that the LLVM backend will lower LLVM IR into JS, and then our existing toolchain scripts will process and optimize it. So we are just replacing one part of emscripten, several thousand lines of code and fairly small compared to the stuff which is not changing. But it should still give us 2 main benefits, in time:

1) faster compilation speed, no need to process IR in JS, can use LLVM IR in C++ directly
2) tighter integration with LLVM should allow us to avoid some current limitations, like overly pessimistic alignment

The backend is far from complete, but for all "basic" codegen, appears to work fine and passes the test suite. That includes building complex things like python, bullet, cubescript, etc., but does *not* include anything complex and requiring special support like C++ exceptions, setjmp/longjmp, and various compiler flags like SAFE_HEAP etc.

In time we can support all those things, although there are some features we never will - the new compiler will stay streamlined by focusing on one mode of codegen, optimized and relooped asm.js, as opposed to the old compiler which supported several other modes (non-asmjs typed arrays, and no typed arrays). Of course the old compiler will remain viable for things that need those codegen modes. Otherwise, things like C++ exceptions etc. should certainly be supported in the new compiler and are just a matter of time and how much people need them.

Note that, as mentioned in that link, the compiler is not much optimized or polished yet. The first goal is correctness. Although, even without any optimization for compilation speed, it already beats the old compiler on that by a large margin. Performance of the generated code will be slower though, until we spend time optimizing it. It should eventually be faster than the current compiler though, for the integration reasons mentioned earlier.

The link above has instructions to build and test the new compiler. If you have a codebase that does not need exceptions or setjmp, please test on the new compiler and file issues if you find any! And if you are interested in helping to finish the backend, that would be great too.

- Alon

Re: LLVM backend for emscripten Ehsan Akhgari 12/19/13 6:32 PM
This is great news!  I've been looking forward to this for so long, congratulations on the great undertaking!



--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

This message has been hidden because it was flagged for abuse.
Re: LLVM backend for emscripten azakai 12/19/13 9:14 PM
We could emit something close to asm but with heap resizing, but it would not be as optimizable because the heap would not be constant. Without proper browser support, our options are limited I'm afraid.

- Alon



--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

This message has been hidden because it was flagged for abuse.
Re: LLVM backend for emscripten azakai 12/19/13 9:53 PM
I don't think it would buy us anything over what you are currently doing, though. It would look superfically more similar, but the underlying issues would remain (heap can change, so js engines optimize less, and we must limit our eliminator as well).

- Alon

This message has been hidden because it was flagged for abuse.
Re: LLVM backend for emscripten azakai 12/20/13 4:29 PM
Oh, in that sense, now I get you. We should be able to make the new compiler work with that very easily, just with the same limitations as before.

- Alon

This message has been hidden because it was flagged for abuse.