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.
