The issue here is that we trial-inline a self-hosted call, trigger relazification, then try to call the trial-inlined function. Unlike other functions, self-hosted lazy functions do not have a BaseScript. Instead, we have a fake `SelfHostedLazyScript` per-runtime that contains a trampoline pointer. In general, this is good enough for jitcode. However, when we call a trial-inlined function, we have to guard that it has a `BaselineScript`, and the first step is to check if it has a `JitScript`.
To make `branchIfScriptHasNoJitScript` work for self-hosted lazy functions, this patch adds a warm-up data field to `SelfHostedLazyScript`.
Differential Revision: https://phabricator.services.mozilla.com/D89848
In this patch we add a tls dependency for the remaining nodes which use
BuiltinThunk to call c++ runtime. By ABI requirements WasmTlsReg should
be set.
Differential Revision: https://phabricator.services.mozilla.com/D89239
We generate builtin call for Mod operation for Double types, so we need
to add a tls dependency. In this patch I've added it.
Differential Revision: https://phabricator.services.mozilla.com/D89243
The callee getter returned |undefined| for certain functions because it's
hard to recover the callee consistently for all environments (and we can't
return the internal canonical function). See also bug 1414684.
This patch fixes that by exposing the script instead of the callee. Devtools is
only interested in the displayName and parameterNames properties and those are
also available on scripts (the previous patch adds Script.parameterNames).
Differential Revision: https://phabricator.services.mozilla.com/D89701
Simplifies the implementation of Debugger.Object.parameterNames (for functions)
and reuses it for scripts. The test is based on the Object-parameterNames.js
test with some minor changes and the documentation is based on the Object docs.
Devtools code will use this in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D89700
x86 has few register so to do div/mod for i64 it call the runtime
and clobber almost all gp registers including WasmTlsReg.
To be able to call c++ runtime via Builtin thunk we need to set up WasmTlsReg.
In this patch I create dependencies from MIR level to Codegen to be sure that WasmTlsReg is alive
when we call runtime.
Differential Revision: https://phabricator.services.mozilla.com/D88524
Here we remove remaining uses of Frame::tls. There are many places where
we use it: in debug frames, in profiling frames, in jit activation, etc.
All these places require short fixes to use our new scheme for getting
tls, so I gathered them together.
Differential Revision: https://phabricator.services.mozilla.com/D83051
Depends on D83045
Here we replace usage of Frame::tls in frame iteration with GetNearestEffectiveTls.
We also maintain current tls for frame iteration object to not to call GetNearestEffectiveTls everytime.
Differential Revision: https://phabricator.services.mozilla.com/D83045
Depends on D83044
This is the third part of series of patches to Frame without tls pointer.
Here we preserve initial tls in all entry stubs and then use it to find a proper tls instance for a given frame.
To find the TlsData* for specific frame we start from a entry stub's tls
and then track tls through all possible cross-instance calls. This logic
is implemented in GetNearestEffectiveTls procedure.
Then, we use this new procedure to make singal handling free from Frame::tls.
Differential Revision: https://phabricator.services.mozilla.com/D83044
Depends on D82888
This is a followup patch for removing Frame::tls.
Now, we are preserving caller's and callee's tls'es for all possible cross-instance calls in the previously allocated abi slots.
We also use preserved tls values to restore the caller's tls in Ion. Baseline doesn't need this because it restores the caller tls from its private stack slot after the call.
Differential Revision: https://phabricator.services.mozilla.com/D82888
Depends on D82881
We are going to remove Frame::tls and support trampolines for indirect calls, so we need to get rid of using Frame::tls.
In this and the followup patches I will iteratively remove all dependencies of Frame::tls and remove it eventually.
In this patch I changed wasm ABI to allocate two stack slots after stack args to preserve caller's and callee's tls'es in the near future.
Differential Revision: https://phabricator.services.mozilla.com/D82881
x86 has few register so to do div/mod for i64 it call the runtime
and clobber almost all gp registers including WasmTlsReg.
To be able to call c++ runtime via Builtin thunk we need to set up WasmTlsReg.
In this patch I create dependencies from MIR level to Codegen to be sure that WasmTlsReg is alive
when we call runtime.
Differential Revision: https://phabricator.services.mozilla.com/D88524
We generate builtin call for MTruncateToInt32 operation for floating points types,
so we need to add a tls dependency.
I inserted NYI for arm64 because Ion doesn't support arm64.
Differential Revision: https://phabricator.services.mozilla.com/D89550
We generate builtin call for Mod operation for Double types, so we need
to add a tls dependency. In this patch I've added it.
Differential Revision: https://phabricator.services.mozilla.com/D89243
In this patch we add a tls dependency for the remaining nodes which use
BuiltinThunk to call c++ runtime. By ABI requirements WasmTlsReg should
be set.
Differential Revision: https://phabricator.services.mozilla.com/D89239
To be able to call c++ runtime via Builtin thunk we need to set up WasmTlsReg.
In this patch I create dependencies from MIR level to Codegen to be sure that WasmTlsReg is alive
when we call runtime in div/mod i64 for arm.
Differential Revision: https://phabricator.services.mozilla.com/D88762
x86 has few register so to do div/mod for i64 it call the runtime
and clobber almost all gp registers including WasmTlsReg.
To be able to call c++ runtime via Builtin thunk we need to set up WasmTlsReg.
In this patch I create dependencies from MIR level to Codegen to be sure that WasmTlsReg is alive
when we call runtime.
Differential Revision: https://phabricator.services.mozilla.com/D88524
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
I was thinking about writing an [SMDOC] comment until I realized we already had one. I settled for a few updates to that comment and some annotations on the ASCII diagrams.
Differential Revision: https://phabricator.services.mozilla.com/D89524
This patch hoists the stub frame / rectifier frame code into its own function. The next patch splits that function up.
Differential Revision: https://phabricator.services.mozilla.com/D89521
The `invalidate` argument to `BailoutIonToBaseline` and `InitFromBailout` was only used for a single assertion in the IonReturnOverride case, which could be more directly asserted in `jit::Bailout`.
Differential Revision: https://phabricator.services.mozilla.com/D89517
I would like to add a comment here explaining *why* we have to overwrite the arguments in the caller, but I'm not confident I understand myself.
Similarly, I tried rewriting the comment about not updating when the arguments object aliases the formals ("In such cases, the list of arguments reported by the snapshot are only aliases of argument object slots..."), but I wasn't sure I understood.
Differential Revision: https://phabricator.services.mozilla.com/D89514
Caroline Cullen
Tooru Fujisawa
Denis Palmeiro
Iain Ireland
Dmitry Bezhetskov
Jon Coppeard
Jan de Mooij
Butkovits Atila
Tarek Ziadé
Bogdan Tara
Cosmin Sabou
Gerald Squelart
Csoregi Natalia