This sounds neat! I've been pondering on an 'early-executor' and this is a really nice demonstration of both viability and utility.
The things I've been thinking about is attempting to start running `main` as far as possible, so non-deterministic functions would end up bubbling up to the beginning. Are there any simple asm.js interpreters (i.e. reduced js interpreter) you're aware of? I suppose would need to be the first step - unlike the 'global ctors' work which looks like it effectively does 'dirty checking', I'd imagine this pass doing data dependency analysis to skip over e.g. `printf` calls since they might not have much impact on the actual flow of code (depending on the memory accesses etc inside these calls). On 8 March 2016 at 23:25, Alon Zakai <[email protected]> wrote: > The incoming branch (now 1.36.1) now has a new optimization when building > to JS with -Oz. It will eliminate C++ global constructor functions > aggressively, removing them from the codebase, removing the need to call > them during startup, and removing code that would otherwise be used only by > them. > > This makes -Oz when compiling to JS slower to compile than before, almost > 2x slower. To avoid that, you can disable this optimization (-s > EVAL_CTORS=0), or just use -Os. In general, -Oz is kind of the "try at all > costs to reduce code size", so it felt natural to include this optimization > there. > > The benefit can be noticeable. For example, this removes the 2 global > ctors that doing any C++ iostream usage would normally bring in, that > create the standard streams. This reduces code size by a few percent, as > well as JS compilation time, and startup is faster also because we can jump > right to executing main(). In general, of course, we can't remove all > ctors, as it might do something with side effects like printf or malloc, > which we can't optimize away. With EMCC_DEBUG=1 in the env, you'll see > logging that shows an error in such a case (which you can use to optimize > your codebase, if you want). > > This optimization was inspired by Cheerp's PreExecutor ( > http://blog.leaningtech.com/2016/02/cheerp-preexecuter-compile-time.html > ). That made me wonder, doesn't LLVM already do this? Turns out, yes, it > does, but at the IR level, and as a result is not as successful as it could > be, due to the complexity of LLVM IR. But at the asm.js level things are > very simple - in fact, this optimization just literally runs the code in a > JS sandbox, and sees if it ran without using anything nondeterministic. > That's after all the LLVM complexity was lowered out, and is basically > guaranteed to work when it should work. More details at > > https://github.com/kripken/emscripten/blob/incoming/src/settings.js#L699 > > - 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. > -- Aidan Currently co-authoring a book on Docker <http://manning.com/miell/?a_aid=aidanhs&a_bid=e0d48f62> - get 39% off with the code 39miell -- 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.
