On Wed, Dec 17, 2014 at 7:01 PM, Alon Zakai <[email protected]> wrote:
> This just matters for bitcode => JS, so a parallel build of sources to > bitcode would not have any issues. > For what it's worth, I think we produce something like half a dozen independent .js targets from .bc files. > Otherwise, it would be good to add some locking mechanism for stuff like > this, but as discussed in the past, it's not easy to do cross-platform. I'm > open to suggestions. Also I am ok with adding an option to tell emcc to use > a prebuilt copy. > Rather than locking, my preference would be to have an option for building the native optimizer to a specified location, and another option to use said specified location. This would allow someone to express all of these dependencies directly in the SCons or whatever build tool dependency graph, and thus locking isn't required. > > - Alon > > > On Wed, Dec 17, 2014 at 4:31 PM, Bruce Mitchener < > [email protected]> wrote: >> >> Is there a way to tell emcc / whatever to pre-build this or tell it to >> use a pre-built copy? >> >> When emcc builds things as part of a compilation run, it is tough for a >> build system to handle the case where those things don't exist and we have >> multiple simultaneous invocations of emcc in a parallel build ... >> >> - Bruce >> >> >> On Thu, Dec 18, 2014 at 2:46 AM, Alon Zakai <[email protected]> wrote: >> >>> 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. >>> >> -- >> 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. >> > -- > 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. > -- Chad Austin Technical Director, IMVU http://engineering.imvu.com <http://www.imvu.com/members/Chad/> http://chadaustin.me -- 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.
