Strange, I can't seem to get it to use the native optimizers, at least I'm not seeing any 'building native optimizer' or 'js optimizer using native' messages. I'm using the emscripten-sdk with incoming, and I'm seeing the EMCC_NATIVE_OPTIMIZER in tools/js_optimizer.py, what am I doing wrong? :)
Here's the complete console dump: FlohOfWoe:oryol floh$ EMCC_NATIVE_OPTIMIZER=1 sdks/osx/emsdk_portable/emscripten/incoming/emcc -O2 hello.c DEBUG root: PYTHON not defined in ~/.emscripten, using "/usr/bin/python2" DEBUG root: JAVA not defined in ~/.emscripten, using "java" WARNING root: invocation: sdks/osx/emsdk_portable/emscripten/incoming/emcc -O2 hello.c (in /Users/floh/projects/oryol) INFO root: (Emscripten: Running sanity checks) DEBUG root: compiling to bitcode DEBUG root: emcc step "parse arguments and setup" took 0.00 seconds DEBUG root: compiling source file: hello.c DEBUG root: running: /Users/floh/projects/oryol/sdks/osx/emsdk_portable/clang/fastcomp/build_incoming_64/bin/clang -target asmjs-unknown-emscripten -D__EMSCRIPTEN_major__=1 -D__EMSCRIPTEN_minor__=26 -D__EMSCRIPTEN_tiny__=1 -Werror=implicit-function-declaration -nostdinc -Xclang -nobuiltininc -Xclang -nostdsysteminc -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/local/include -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/compat -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/emscripten -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/libc -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/lib/libc/musl/arch/js -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/libcxx -O2 -mllvm -disable-llvm-optzns -emit-llvm -c hello.c -o /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/hello_0.o -Xclang -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/SDL DEBUG root: emcc step "bitcodeize inputs" took 0.01 seconds DEBUG root: optimizing hello.c DEBUG root: emcc: LLVM opts: -O3 DEBUG root: emcc step "process inputs" took 0.29 seconds DEBUG root: will generate JavaScript DEBUG root: including libc DEBUG root: emcc step "calculate system libraries" took 0.01 seconds DEBUG root: linking: ['/var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/hello_0_1.o', '/Users/floh/.emscripten_cache/libc.bc'] DEBUG root: emcc: llvm-linking: ['/var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/hello_0_1.o', '/Users/floh/.emscripten_cache/libc.bc'] to /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/a.out.bc DEBUG root: emcc step "link" took 0.02 seconds DEBUG root: saving intermediate processing steps to /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/emscripten_temp DEBUG root: emcc: LLVM opts: -strip-debug -internalize -internalize-public-api-list=main,malloc,free -globaldce -pnacl-abi-simplify-preopt -pnacl-abi-simplify-postopt DEBUG root: emcc step "post-link" took 0.02 seconds DEBUG root: LLVM => JS DEBUG root: PYTHON not defined in ~/.emscripten, using "/usr/bin/python2" DEBUG root: JAVA not defined in ~/.emscripten, using "java" DEBUG root: not building relooper to js, using it in c++ backend DEBUG root: emscript: llvm backend: /Users/floh/projects/oryol/sdks/osx/emsdk_portable/clang/fastcomp/build_incoming_64/bin/llc /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/a.out.bc -march=js -filetype=asm -o /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/emscripten_temp/tmpKKukJK.4.js -O2 -emscripten-max-setjmps=20 DEBUG root: emscript: llvm backend took 0.0165209770203 seconds DEBUG root: emscript: js compiler glue DEBUG root: emscript: glue took 0.216127157211 seconds DEBUG root: asm text sizes[[105107, 1849, 25], 0, 130, 1180, 0, 0, 29, 274, 234, 663, 348] DEBUG root: emscript: final python processing took 0.00248885154724 seconds DEBUG root: emcc step "emscript (llvm=>js)" took 0.40 seconds DEBUG root: wrote memory initialization to a.out.js.mem DEBUG root: emcc step "source transforms" took 0.01 seconds DEBUG root: running js post-opts DEBUG root: applying js optimization passes: ['asm', 'emitJSON', 'minifyWhitespace'] chunkification: num funcs: 7 actual num chunks: 1 chunk size range: 108251 - 108251 . DEBUG root: applying js optimization passes: ['asm', 'receiveJSON', 'eliminate', 'simplifyExpressions', 'simplifyIfs', 'registerize', 'minifyNames', 'emitJSON', 'minifyWhitespace'] chunkification: num funcs: 3 actual num chunks: 1 chunk size range: 307159 - 307159 . DEBUG root: applying js optimization passes: ['asm', 'receiveJSON', 'cleanup', 'asmLastOpts', 'last', 'minifyWhitespace'] chunkification: num funcs: 3 actual num chunks: 1 chunk size range: 162909 - 162909 . running cleanup on shell code DEBUG root: emcc step "js opts" took 0.96 seconds DEBUG root: emcc step "final emitting" took 0.00 seconds DEBUG root: total time: 1.72 seconds Am Freitag, 14. November 2014 02:19:47 UTC+1 schrieb Alon Zakai: > > Early this year the fastcomp project replaced the core compiler, which was > written in JS, with an LLVM backend in C++, and that brought large > compilation speedups. However, the late JS optimization passes were still > run in JS, which meant optimized builds could be slow (in unoptimized > builds, we don't run those JS optimizations, typically). Especially in very > large projects, this could be annoying. > > Progress towards speeding up those JS optimization passes just landed, > turned off, on incoming. This is not yet stable or ready, so it is *not* > enabled by default. Feel free to test it though and report bugs. To use it, > build with > > EMCC_NATIVE_OPTIMIZER=1 > > in the environment, e.g. > > EMCC_NATIVE_OPTIMIZER=1 emcc -O2 tests/hello_world.c > > It just matters when building to JS (not building C++ to object/bitcode). > When EMCC_DEBUG=1 is used, you should see it mention it uses the native > optimizer. The first time you use it, it will also say it is compiling it, > which can take several seconds. > > The native optimizer is basically a port of the JS optimizer passes from > JS into c++11. c++11 features like lambdas made this much easier than it > would have been otherwise, as the JS code has lots of lambdas. The ported > code uses the same JSON-based AST, implemented in C++. > > Using c++11 is a little risky. We build the code natively, using clang > from fastcomp, but we do use the system C++ standard libraries. In > principle if those are not c++11-friendly, problems could happen. It seems > to work fine where I tested so far. > > Not all passes have been converted, but the main time-consuming passes in > -O2 have been (eliminator, simplifyExpresions, registerize). (Note that in > -O3 the registerizeHarder pass has *not* yet been converted.) The toolchain > can handle running some passes in JS and some passes natively, using JSON > to serialize them. > > Potentially this approach can speed us up very significantly, but it isn't > quite there yet. JSON parsing/unparsing and running the passes themselves > can be done natively, and in tests I see that running 4x faster, and using > about half as much memory. However, there is overhead from serializing JSON > between native and JS, which will remain until 100% of the passes you use > are native. Also, and more significantly, we do not have a parser from JS - > the output of fastcomp - to the JSON AST. That means that we send fastcomp > output into JS to be parsed, it emits JSON, and we read that in the native > optimizer. > > For those reasons, the current speedup is not dramatic. I see around a 10% > improvement, far from how much we could reach. > > Further speedups will happen as the final passes are converted. The bigger > issue is to write a JS parser in C++ for this. This is not that easy as > parsing JS is not that easy - there are some corner cases and ambiguities. > I'm looking into existing code for this, but not sure there is anything we > can easily use - JS engine parsers are in C++ but tend not to be easy to > detach. If anyone has good ideas here that would be useful. > > - 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/d/optout.
