1826078 - Emit bytecode to copy aliased arguments to the call object

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task, P1)

Description

[Jan de Mooij [:jandem]]

When we create a call object in the interpreter/Baseline, we loop over the script's argument bindings to see which ones we have to copy to the call object. It's more efficient to have the frontend emit bytecode to do this work. This will also make it easier to inline the object allocation itself in Baseline in the future.

I have a patch stack that improves the micro-benchmark below from 82 ms to 55 ms with --no-ion.

function foo(a, b, c) {
    if (a) {
        return () => b + c;
    }
    return null;
}
function f() {
    var t = new Date;
    for (var i = 0; i < 1_000_000; i++) {
        foo(false, 11, 22);
    }
    print(new Date - t);
}
f();

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Bug 1826078 part 1 - Add ParserPositionalFormalParameterIter. r?arai!

This is similar to what we do for BindingIter and ParserBindingIter.

Comment 2

[Jan de Mooij [:jandem]]

Attachment: Bug 1826078 part 2 - Add JSOp::GetFrameArg. r?arai!

This will be used in the next patch to copy arguments to the call object in the prologue.

Depends on D174577

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Bug 1826078 part 3 - Emit bytecode to initialize CallObject slots for arguments. r?arai!

Emit bytecode in the prologue to initialize the slots for closed-over arguments, instead
of doing this at runtime.

This is faster in the interpreter and Baseline because we no longer have to look
at the scope's bindings each time we allocate a call object. It also makes it easier
to optimize the CallObject allocation later.

Depends on D174578

Comment 4

[Jan de Mooij [:jandem]]

Attachment: Bug 1826078 part 4 - Optimize GC barriers for stores to MNewCallObject. r?iain!

The previous patch removed some MIR instructions from WarpBuilder::buildCallObject,
because storing aliased arguments to the call object now happens with bytecode
instructions. Unfortunately that means we lost some optimizations baked into
buildCallObject to elide GC barriers.

This patch adds an optimization pass to optimize the MIR instructions we generate for
the new bytecode sequence in a similar way to what we did manually in buildCallObject.

In the future we could use this to optimize other allocation instructions as well.

Depends on D174579

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/74799e55594a
part 1 - Add ParserPositionalFormalParameterIter. r=arai
https://hg.mozilla.org/integration/autoland/rev/ab307229ef84
part 2 - Add JSOp::GetFrameArg. r=arai
https://hg.mozilla.org/integration/autoland/rev/f49c4de7f846
part 3 - Emit bytecode to initialize CallObject slots for arguments. r=arai
https://hg.mozilla.org/integration/autoland/rev/ee6468bab0dd
part 4 - Optimize GC barriers for stores to MNewCallObject. r=iain

Comment 6

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/74799e55594a
https://hg.mozilla.org/mozilla-central/rev/ab307229ef84
https://hg.mozilla.org/mozilla-central/rev/f49c4de7f846
https://hg.mozilla.org/mozilla-central/rev/ee6468bab0dd