Currently, we don't emit GNAME ops in strict mode. jsemit.cpp explains why: * This conversion is not made if we are in strict mode. In eval code nested * within (strict mode) eval code, access to an undeclared "global" might * merely be to a binding local to that outer eval: * * "use strict"; * var x = "global"; * eval('var x = "eval"; eval("x");'); // 'eval', not 'global' The attached testcase measures global variable access, strict / non-strict: d8 : 129 / 128 js -j : 227 / 256 js -m -n : 427 / 84 js -m : 514 / 511 Without TI there's not much of a difference but this really hurts TI+JM. I don't know the emitter very well but it should be possible somehow to do this NAME -> GNAME optimization outside eval'ed code, right? This affects scripts generated by Emscripten: it seems to use strict mode now and uses globals for the heap etc.

Is there any performance benefit to having emscripten use strict mode? If so this would be a higher priority for us, but if it's just for strict-ness, then we can just not emit use strict..

In theory strict mode could be faster than normal mode, but there is no real benefit now except for debugging.

Instead of never optimizing *NAME => *GNAME ops inside strict-mode code, this patch changes things so that we only stop doing this inside eval code. I now get the same numbers for the testcase in comment 0. I didn't find a way to check for "eval or nested inside eval", so this patch adds a "bool insideEval" to BytecodeEmitter. Initially I checked whether "HandleScript evalCaller" is non-NULL, but this breaks the Debugger's evalInGlobal() (it passes a NULL evalCaller). When I just comment out bce->sc->strict, multiple jit-tests start failing, so I don't think we need more tests for this.