Including SymbolType.h in AtomMarking.h pulls in a ton of vm includes. This
dependency can be moved to the -inl.h which used rarely.
Differential Revision: https://phabricator.services.mozilla.com/D90103
Currently HelperThreads.h defines all the internals of the helper thread
system, but most of this is only neeed by HelperThreads.cpp itself. This patch
splits that out into a separate file so that HelperThreads.h defines an API for
the helper thread system.
Differential Revision: https://phabricator.services.mozilla.com/D90101
This is only used by ubinode and doesn't need to be in the public API. I
removed ZoneSet/CompartmentSet which are otherwise unneeded.
Differential Revision: https://phabricator.services.mozilla.com/D90100
Including SymbolType.h in AtomMarking.h pulls in a ton of vm includes. This
dependency can be moved to the -inl.h which used rarely.
Differential Revision: https://phabricator.services.mozilla.com/D90103
Currently HelperThreads.h defines all the internals of the helper thread
system, but most of this is only neeed by HelperThreads.cpp itself. This patch
splits that out into a separate file so that HelperThreads.h defines an API for
the helper thread system.
Differential Revision: https://phabricator.services.mozilla.com/D90101
This is only used by ubinode and doesn't need to be in the public API. I
removed ZoneSet/CompartmentSet which are otherwise unneeded.
Differential Revision: https://phabricator.services.mozilla.com/D90100
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
`Object.prototype.isPrototypeOf` can directly be inlined through the existing
`MInstanceOf` mir node resp. the `LoadInstanceOfObjectResult` CacheIR op.
Differential Revision: https://phabricator.services.mozilla.com/D89735
The shareable code with the existing `tryAttachString()` was minimal, therefore
a separate function was added to handle the case when `String()` is called as a
constructor.
Differential Revision: https://phabricator.services.mozilla.com/D89459
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
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
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
Tooru Fujisawa
Jon Coppeard
Csoregi Natalia
Doug Thayer
André Bargull
Jan de Mooij
Dorel Luca
Dmitry Bezhetskov
Caroline Cullen
Denis Palmeiro
Iain Ireland
Butkovits Atila
Tarek Ziadé
Bogdan Tara