I just merged code to enable the new native optimizer by default. This means that the "js opts" phase in -O2 and above will use new C++ code instead of the old JS code. This generally speeds up that phase by more than 3x, and since this phase is often the slowest, can have a significant positive effect on -O2 and above build times.
In the big picture, this concludes the 2nd of two major code upgrades this year - first to replace the JS compiler with an LLVM backend in C++, and now to replace the JS optimizer. The native optimizer code is written in c++11, and depends on having a c++11 compiler and runtime library. This might not be available everywhere; if building it fails, emcc will automatically use the old optimizer. You can see messages regarding that in debug mode output (EMCC_DEBUG=1 in the environment). I believe we saw that the native optimizer wouldn't build on the windows bot, and clb disabled the test verifying build success on it (other.test_native_optimizer). We should probably look more into why it fails now. I added a new test mode, asm2nn, which runs the non-native optimizer (i.e. the old one), to keep test coverage of the case where the native optimizer can't be built. To offset the extra bot test time, I disabled slow2asm, which tested the old pre-fastcomp compiler in asm.js mode. I'm not aware of anyone using that mode - let me know if disabling those tests concerns you. Note that bot test times should improve since all the other optimized test modes will use the native optimizer, which is faster. Please test this on your codebases! :) All you need to do is pull latest incoming (on all 3 repos), which is version 1.28.2, and use that - the native optimizer will be utilized by default. Check in EMCC_DEBUG=1 output if it says, somewhere after "running js post-opts", something like "js optimizer using native". That implies the native optimizer is used. Otherwise, you might see a warning message. You can manually disable the native optimizer, if you want, with EMCC_NATIVE_OPTIMIZER=0 in the env. However, as mentioned before, emcc will fall back to the JS optimizer if it fails to build the native optimizer, so you shouldn't need to do so (unless perhaps you find a bug in the native optimizer?). - Alon P.S. The native optimizer parses asm.js code, optimizes it, and emits that asm.js code. To parse and unparse, I wrote a new standalone library for that purpose, called cashew, https://github.com/kripken/cashew It might be useful if you want a C++ library for parsing asm.js code. -- 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/d/optout.
