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 -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
