This is part of JSSP removal for arm64. The padding is needed so
that the extra arguments, which are pushed separately from the rest
of the arguments, will take up an even number of slots, to avoid
copying the rest of the arguments one slot down.
Bug: v8:6644
Change-Id: I00a8730c375e4b4cc8fa0c8b6372751f92754466
Reviewed-on: https://chromium-review.googlesource.com/713255
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48547}
Adds some necessary padding to ensure the frame is 16-byte aligned.
We don't yet consider the bailout state, which will be handled separately.
This patch also improves the code generated for ContinueTo*Builtin* stubs.
Finally, it adds a test that checks the return value for Array.map in
the case where a LAZY deopt results in a topmost builtin continuation
frame - this is easy to break if the padding for the result is done
incorrectly in NotifyBuiltinContinuation, but was not detected by existing
tests.
Bug: v8:6644
Change-Id: Id1a294950cdf535e2bfdb0ed27c67f077ec34f8a
Reviewed-on: https://chromium-review.googlesource.com/704835
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48465}
Pair some stack ops so that they deal with an even numbers of registers, add
padding around profile entry calls, and delete some unused macro assembler code.
Bug: v8:6644
Change-Id: I5a5529f04738ba2a2fdb1b0d4ee93c567a3c504e
Reviewed-on: https://chromium-review.googlesource.com/686823
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#48205}
Add padding for the interpreter registers when needed, to make the
interpreter frame a multiple of 16 bytes. The padding needs to be added
in the InterpreterEntryTrampoline and when generating an interpreter
frame in the deoptimizer. It also needs to be considered when
calculating the size of the interpreter frame during OSR and stack
unwinding.
Bug: v8:6644
Change-Id: Icfec94079cf0785fc8a2506ff555b5f9e89e3d13
Reviewed-on: https://chromium-review.googlesource.com/664563
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48121}
Removes the new.target slot from the interpreter's fixed frame. Instead
adds a field to BytecodeArray to get the bytecode's incoming
new.target or generator object register. The InterpreterEntryTrampoline
then sets this register with the incoming new.target (or generator object)
when the function is called. This register can be directly the new.target
or generator object variable if they are LOCAL location, otherwise it is a
temporary register which is then moved to the variable's location during the
function prologue.
This fixes a hack in the deoptimizer where we would set the new.target fixed
slot to undefined in order to avoid extending it's lifetime through the
optimized code - now it's just a standard register and can be optimized away
as normal.
Bug=v8:6644
Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
Reviewed-on: https://chromium-review.googlesource.com/608966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47320}
