Good point, we should hide that output by default. Fixing now. - Alon
On Thu, Dec 18, 2014 at 6:41 AM, Floh <[email protected]> wrote: > > Tested on the Oryol samples and everything is working, but I encountered 2 > somewhat confusing problems: > > - after updating incoming via emsdk linking failed with a messy dump of > python backtraces (unfortunately haven't copied it) and an optimizer > assertion complaining about a missing file, this was fixed by manually > running 'emcc --clear-cache' > > - next it looked like the optimizer failed to compile (on OSX, this was a > know issue) because of missing C++ std header files because compiler errors > were dumped to the console during linking (see below), but it turns out > that this is from the part where several compilers are tested whether they > can successfully compile the optimizer. In the end it worked (there's a new > ~/.emscripten_cache/optimizer.exe), but the output is very confusing, may > be it's possible to catch and drop stdout/stderr during the compile? > > Here's the output that confused me: > > Linking CXX executable ../../../../../../../bin/emsc/Clear.html > In file included from > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/tools/optimizer/parser.cpp:2: > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/tools/optimizer/parser.h:6:10: > fatal error: 'vector' file not found > #include <vector> > ^ > 1 error generated. > In file included from > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/tools/optimizer/simple_ast.cpp:2: > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/tools/optimizer/simple_ast.h:8:10: > fatal error: 'vector' file not found > #include <vector> > ^ > 1 error generated. > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/tools/optimizer/optimizer.cpp:1:10: > fatal error: 'cstdint' file not found > #include <cstdint> > ^ > 1 error generated. > [100%] Built target Clear > > Cheers, > -Floh > > Am Mittwoch, 17. Dezember 2014 20:46:08 UTC+1 schrieb Alon Zakai: > >> 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.
