I have some patches to store the IC index (= number of JOF_IC ops) in jump target ops. The interpreter will use this to set the frame's ICEntry* pointer at jump target ops and then it will just bump this pointer after each JOF_IC op. This way the interpreter can use Baseline ICs with minimal overhead compared to the Baseline JIT.

This is easier now that the BCE prologue/main split is gone (bug 1284719) and we can assert correctness in ICScript::create.

Depends on D17112

The bytecode emitter used to call checkTypeSet for each JOF_TYPESET op. Despite
correctness asserts in the TypeScript code, this was pretty error prone. Doing
something similar for JOF_IC ops would have made it worse.

The solution is to move this check to BytecodeEmitter::emitCheck (called for
each opcode we emit), so we don't have to worry about this anymore.

Depends on D17113

The interpreter will use this to set the frame's ICEntry* pointer at jump target
ops and then it will just bump this pointer after each JOF_IC op. This way the
interpreter can use Baseline ICs with minimal overhead compared to the Baseline
JIT.

Depends on D17114

Backed out changeset 159930eacfd7 (bug 1521491) for spidermonkey failure

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=224454044&repo=autoland&lineNumber=6041

Push with failures:
https://hg.mozilla.org/integration/autoland/rev/159930eacfd7a4a9933d26655f017def45919948

Backout:
https://hg.mozilla.org/integration/autoland/rev/536917ba6bcf6a88d83f6d7551a50086cbdee1e9

Silly rooting hazard while emitting JSOP_LABEL. Maybe now is a good time to stop using JOF_JUMP for JSOP_LABEL.

JSOP_LABEL isn't a jump instruction at all. This patch adds JOF_CODE_OFFSET and
uses it for JSOP_LABEL. This lets us simplify some code and avoids a rooting
hazard with the next patch.

https://hg.mozilla.org/mozilla-central/rev/2058451bd944
https://hg.mozilla.org/mozilla-central/rev/92a00136c2fd
https://hg.mozilla.org/mozilla-central/rev/a9a95a138e04

Oh wait, parts 4 and 5 still need to merge to m-c but didn't yet because of the big ChromeUtils.import changes. Should happen soon though.

https://hg.mozilla.org/mozilla-central/rev/731a43e841ab
https://hg.mozilla.org/mozilla-central/rev/037f2dd3a63f

It looks like there was a 38K base memory regression associated with this.

Jan, is this something we can work around or do we need to accept the regression?

Bug 1523749 will gain back most of this regression, but some of it will probably remain for perf reasons.

What Ted said. We'll have to accept this one for now unfortunately.