Make the WebAssembly ion compiler address incoming stack arguments from the frame pointer instead of from the stack pointer.
We have a plan to allow interstitial trampoline frames to be inserted between callers and callees, but only for cross-instance calls. This will mean offset to incoming stack arguments from SP is no longer a constant. The design has us instead address stack arguments from the frame pointer, as adding an interstitial trampoline frame won't modify the frame pointer.
Differential Revision: https://phabricator.services.mozilla.com/D73030
These pragmas can be used to influence stack trace filenames, and to affect
how and where files show up in developer tools. In some circumstances, it can
be nice to disable allof that functionality in order to ensure that you get
the stack trace and debug information as SpiderMonkey sees it.
Differential Revision: https://phabricator.services.mozilla.com/D72103
Assert that trace list visits children before parents. Make this explicit
instead of relying on existing publishDeferredFunctions checks so that we
check for non-lazy functions as well for more certainty.
Differential Revision: https://phabricator.services.mozilla.com/D74440
The FunctionBoxes are added to head of the trace-list as they are created in
source order. This means the final list is the reverse of that and inner
functions are seen before their parent. This is exactly what we need for the
publishDeferredFunctions method.
Differential Revision: https://phabricator.services.mozilla.com/D74313
This also unifies the list between the syntax- and full-parser which is
sensible since the allocations are on a shared LifoAlloc.
Differential Revision: https://phabricator.services.mozilla.com/D74311
This data can instead be accessed from CompilationInfo. As well, the only use
is to allocate lazy BaseScripts and that code is being moved outside the
Parser.
Differential Revision: https://phabricator.services.mozilla.com/D74302
Make the WebAssembly ion compiler address incoming stack arguments from the frame pointer instead of from the stack pointer.
We have a plan to allow interstitial trampoline frames to be inserted between callers and callees, but only for cross-instance calls. This will mean offset to incoming stack arguments from SP is no longer a constant. The design has us instead address stack arguments from the frame pointer, as adding an interstitial trampoline frame won't modify the frame pointer.
Differential Revision: https://phabricator.services.mozilla.com/D73030
There was a missing guard when freeing the SIMD result register; it
was freed unconditionally, but this would fail for br_table, when only
the int register is needed.
There was a missing case when materializing constants during
popStackResults, we need to handle V128 here.
In both cases the underlying cause was iffy test coverage, though in
the latter case the problem is also that we allow the use of switch
with default for enum class value sets, thus masking problems where a
case that must be covered is not covered.
Differential Revision: https://phabricator.services.mozilla.com/D74380
This diff adds a test using gczeal to trigger a GC crash caused by the BigInt/I64 conversion path in inlined Ion To Wasm calls.
The actual fixes for the crash are in bug 1633714.
Differential Revision: https://phabricator.services.mozilla.com/D73111
This is part 5 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds additional Wasm BigInt tests that are aimed specifically to test limits of the inlined calls and
to test more conversion cases that should be covered (e.g., to test ToBigInt instruction cases).
Differential Revision: https://phabricator.services.mozilla.com/D65238
This is part 4 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds the support for I64/BigInt arguments for inlined calls in the MCallOptimize.cpp part of
the IonBuilder. With this commit, the I64 arguments will work on 64-bit platforms, except where arguments
are required to be spilled to the stack due to the ABI (this case is more complicated to support).
On 32-bit platforms, this commit disables the BigInt/I64 support for the inlined call as it does not work
without further changes.
Differential Revision: https://phabricator.services.mozilla.com/D65237
This is part 3 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds changes needed in code generation and Wasm stubs for supporting the I64 arguments for
inlined Ion to Wasm calls.
Differential Revision: https://phabricator.services.mozilla.com/D65236
This is part 2 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds an I64 return value case for LIonToWasmCall, which is needed in general because an I64
result may require multiple defs for the instruction.
Differential Revision: https://phabricator.services.mozilla.com/D65234
This is part 1 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part implements Ion MIR and LIR instructions that are needed for conversion between BigInts and I64.
Differential Revision: https://phabricator.services.mozilla.com/D65233
Dmitry Bezhetskov
Sylvestre Ledru
Tooru Fujisawa
Tom Schuster
Logan Smyth
Ted Campbell
Steve Fink
Jan de Mooij
Csoregi Natalia
Lars T Hansen
Mike Hommey
Jeff Walden
Asumu Takikawa
Sonia Singla
Razvan Maries
Andreea Pavel
Florian Quèze