1605648 - Stop relying on JSFunction::INTERPRETED in IonMonkey call code

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, task, P2)

Description

[Ted Campbell [:tcampbell]]

Currently we generate code that checks callee for INTERPRETED flag when handling call opcodes. After Bug 1529456, this flag will only indicate the presence of a js::BaseScript, not whether it is compiled.

This means that code paths that used the no-args-check version need a different system for ensuring JitScript is available. As a transition mechanism, these patches introduce MacroAssembler::loadJitCodeMaybeNoArgCheck that guards for lazy function clones and calls back to the jitCodeRaw_ entry as needed. This is the current behaviour of visitCallKnown.

Once lazy and non-lazy scripts unify, the JITs will not have to worry about this condition anymore and the fallback behavior can be removed and an unconditional access may be used. This would remove guards that exist today.

Comment 1

[Ted Campbell [:tcampbell]]

Attachment: Bug 1605648 - Cleanup CodeGenerator::visitCallGeneric. r?jandem

Group the jitCodeRaw handling so it becomes simpler. By changing the scratch
register used by switchToObjectRealm we can move it later in code.

Comment 2

[Ted Campbell [:tcampbell]]

Attachment: Bug 1605648 - Factor out MacroAssembler::loadJitCodeMaybeNoArgCheck. r?jandem

When IonMonkey uses the no-arg-check entry point, we may still see lazy
function clones. In this case the no-arg-check entry point is unavailable,
but we can still fallback to the standard jitCodeRaw. This patch factors this
fallback behaviour out of visitCallKnown.

The new version guards the warmUpData tag bits instead of loading the
function flags. This makes it compatible with removing the INTERPRETED_LAZY
flag. In the future, the fallback case will no longer be necesarry once
delazification reuses the same script and all function clones delazify at
same time as their canonical one does.

Depends on D58096

Comment 3

[Ted Campbell [:tcampbell]]

Attachment: Bug 1605648 - Use masm.loadJitCodeMaybeNoArgCheck for visitGenericCall. r?jandem

Use the same jitCodeRaw fallback strategy that visitKnownCall does to handle
potential lazy clones. We also stop allowing natives to flow into the
no-args-check case to avoid needing to guard against them.

Depends on D58097

Comment 4

[Ted Campbell [:tcampbell]]

Attachment: Bug 1605648 - Remove now-unused MacroAssembler helpers. r?jandem

Depends on D58098

Comment 5

[Ted Campbell [:tcampbell]]

Part 1 is useful today and simplies the lazy-script merge later.

The later parts simplify CodeGenerator, by moving the complexity into MacroAssembler. The macroassembler side can then be simplified in the future once the fallback-to-jitentry is no longer needed. I think it is useful to land these parts now, but we could also handle in future.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f6ce57edcf0d
Cleanup CodeGenerator::visitCallGeneric. r=jandem
https://hg.mozilla.org/integration/autoland/rev/3c68364a0d9c
Factor out MacroAssembler::loadJitCodeMaybeNoArgCheck. r=jandem
https://hg.mozilla.org/integration/autoland/rev/36766794fb83
Use masm.loadJitCodeMaybeNoArgCheck for visitGenericCall. r=jandem
https://hg.mozilla.org/integration/autoland/rev/9ee133ac5de6
Remove now-unused MacroAssembler helpers. r=jandem

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/f6ce57edcf0d
https://hg.mozilla.org/mozilla-central/rev/3c68364a0d9c
https://hg.mozilla.org/mozilla-central/rev/36766794fb83
https://hg.mozilla.org/mozilla-central/rev/9ee133ac5de6