This prologue is not needed any more now that we have the jump table.
If optimized code exists, we will not even enter the Liftoff code any
more, but instead jump to the optimized code right away.
This also allows to remove the {WASM_CODE_TABLE_ENTRY} relocation info
kind.
R=mstarzinger@chromium.org
Bug: v8:7758
Change-Id: I0449693d7434088fb264104fe59365d7ca2b74c6
Reviewed-on: https://chromium-review.googlesource.com/1110222
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53954}
This CL reverts commit 38bec2eadc and
implements the same functionality via Assembler::RecordRelocInfo.
Bug: v8:6666
Change-Id: I2e6b60697f68e956257f4c0877342da1bffca361
Reviewed-on: https://chromium-review.googlesource.com/1107710
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53911}
This CL attempts to simplify the Assembler's dependency on the
isolate, in particular on a global "serializer_enabled" mode contained
therein. The "serializer_enabled" condition enabled and disabled
a number of things in both the assemblers and macro assemblers. To
make these dependencies explicit, the Assembler::IsolateData is refactored
to be a proper Assembler::Options struct that controls specific assembler
behaviors, with default settings easily computable from the isolate.
This also helps make the contract for compiling WASM code more explicit
(since WASM code needs to have reloc info recorded for external references)
we can explicitly enable this recording without trying to "trick" the
assembler using "serializer_enabled".
R=jgruber@chromium.orgCC=mstarzinger@chromium.org, herhut@chromium.org
Change-Id: I7a8ba49df7b75b292d73ec2aa6e507c27a3d99c8
Reviewed-on: https://chromium-review.googlesource.com/1105982
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53890}
When encountering a LoadStackPointer input to a comparison, generate a register
LocationOperand that points to the stack pointer. This can avoid unnecessary
spilling of the stack pointer.
Since sp is a special register for arm64, we need to add a mechanism to print
its name in RegisterConfiguration.
This is a port of https://chromium-review.googlesource.com/1055568 that made
the same change for arm.
It also ports the tests added in
https://chromium-review.googlesource.com/1099068 to arm and arm64.
Bug: v8:7844
Change-Id: I5adc672ff877b9888ef755e8e60e4eabbc61061b
Reviewed-on: https://chromium-review.googlesource.com/1107810
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#53889}
We can instead pass the deopt id in a register, where before we were passing the
deopt entry address. This removes the need for the deopt tables altogether,
saving 192kB.
Change-Id: I479d4de1a0245de328720b6b03a1955c8c63f696
Reviewed-on: https://chromium-review.googlesource.com/1076472
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#53863}
This removes special casing in the handling of {RelocInfo::CODE_TARGET}
for cases where such references appeared in {WasmCode}. Such references
can only appear in real {Code} objects and also only target real {Code}
objects by now.
R=clemensh@chromium.org
Change-Id: I87c55c60cd6344bb67fa8c8d04b66fb523d07ba7
Reviewed-on: https://chromium-review.googlesource.com/1104680
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53848}
Since https://crrev.com/2951473002, there is only one reloc info for
code targets, so there is no need for the special {kCodeTargetMask}.
R=mstarzinger@chromium.org
Bug: v8:7754
Change-Id: I1055108c0128c7de0f5cfefc5e90bbd9dc75522a
Reviewed-on: https://chromium-review.googlesource.com/1098663
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53776}
The jump optimization maybe run Turbofan pipeline twice for each TF/CS builtins,
and relies on the fact that the number of j/jmp instruction generated is always
the same.
This CL introduces a verification process to ensure that instruction sequence
and virtual registers are always the same in two stages, before the final
code generation phase.
R=danno@chromium.org, jarin@chromium.org
Bug: v8:7839
Change-Id: Id77e9bc80f54f79d7a845315e0b99e3f4b6a54fb
Reviewed-on: https://chromium-review.googlesource.com/1100491
Commit-Queue: Kanghua Yu <kanghua.yu@intel.com>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53774}
Extract code generation (for the trampoline) from {wasm-code-manager.cc}
to a new {JumpTableAssembler}. This prepares a CL to add more logic to
the {JumpTableAssembler} to also generate jump tables for lazy
compilation and tier up.
R=mstarzinger@chromium.org
Change-Id: I383585b7e4b5a4af3ca08d07e374b44654c1a09f
Reviewed-on: https://chromium-review.googlesource.com/1046585
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53729}
Lift the declaration of the heap allocation request list and the method
which adds to the list up to AssemblerBase.
Change-Id: I099260425af8cb579144998c71c538f19ba00e65
Reviewed-on: https://chromium-review.googlesource.com/1098959
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53708}
This makes sure that reloc entries with WASM_STUB_CALL mode can be
shared within the constant pool. Call sites to such stubs never need to
be patched individually and absolute addresses of such call targets can
be shared when they are put into constant pools.
This applies to ARM, ARM64 and PPC architectures only.
R=clemensh@chromium.org
BUG=chromium:850413
Change-Id: I657248f61f122f1a3d6d30ebd14326df45f67540
Reviewed-on: https://chromium-review.googlesource.com/1091055
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53603}
Struct fields should not end in an underscore according to the style
guide.
Drive-by: Add {TurboAssembler} constructor which receives an
{IsolateData} directly, to allow creating a {TurboAssembler} in a
background thread.
R=mstarzinger@chromium.org
Change-Id: I32800476690f4c8619059519b7d27b06f5d4be95
Reviewed-on: https://chromium-review.googlesource.com/1090278
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53582}
The slots for imported functions are unused by now. Shrink the table to
only store pointers for non-imported functions (i.e. wasm functions
defined in this module).
R=mstarzinger@chromium.org
Change-Id: I6d13f889528b42beca73c860a800bde7a8e921ab
Reviewed-on: https://chromium-review.googlesource.com/1084845
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53493}
This makes stack checks in WasmCode independent of the underlying
Isolate by loading the limit address from the WasmInstanceObject instead
of embedding it into the instruction stream. It hence removes the last
use of the Isolate field from WasmGraphBuilder.
Additionally this introduces the notion of a "runtime stub" which
represents stub code global to the NativeModule that can be directly
called from each WasmCode in the same module. These stubs can act as
trampolines via which Isolate-independent WasmCode can enter other V8
builtins or runtime functions that remain Isolate-dependent. They will
eventually replace the current "trampoline" in a NativeModule.
R=titzer@chromium.org
BUG=v8:7424
Change-Id: Ie1f5582ee656b1ab7716ea06316d6e21a0268e74
Reviewed-on: https://chromium-review.googlesource.com/1078732
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53487}
This addresses one of the major remaining slowdowns with embedded
builtins on x64.
When generating code for a call to a builtin callee from a builtin
caller, we'd look up the Code target object from the builtins constant
list, calculate the location of the first instruction, and jump to it.
Note that for embedded builtin callees, the Code object is itself only
a trampoline to the off-heap code and thus an additional indirection.
An example of the call sequence in pseudo-asm:
// Load from the constants list.
mov reg, [kRootPointer, kBuiltinsConstantListOffset]
mov reg, [reg, offset_of_the_code_constant]
// Calculate first instruction and call it.
add reg, Code::kHeaderOffset
call reg
// The trampoline forwards to the off-heap area.
mov kOffHeapTrampolineRegister, <off-heap instruction_start>
jmp kOffHeapTrampolineRegister
This CL changes calls to embedded builtin targets to use pc-relative
addressing. This reduces the above instruction sequence to:
call <pc-relative offset to target instruction_start>
Embedded-to-embedded calls jump directly to the embedded instruction
stream, bypassing the trampoline. Heap-to-embedded calls (and all
calls to heap-builtins) use pc-relative addressing targeting the
on-heap Code object.
Other relevant platforms (arm,arm64,mips,mips64) do not use pc-relative
calls. For these, we'll need a different solution, e.g. a table of
embedded builtin addresses reachable from the root pointer, similar to
the external reference table.
Bug: v8:6666
Change-Id: Ic0317d454e2da37d74eaecebcdfcbc0d5f5041ad
Reviewed-on: https://chromium-review.googlesource.com/1068732
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53349}
The (currently four, soon five) RelocIterator constructors contain
basically identical logic. Refactor that into a basic version that all
other constructors call.
Bug: v8:6666
Change-Id: Ice7b4891d5e539ff6fe63337fc52d480d85dc270
Reviewed-on: https://chromium-review.googlesource.com/1059109
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53189}
Stubs and builtins are very similar. The main differences are that
stubs can be parameterized and may be generated at runtime, whereas
builtins are generated at mksnapshot-time and shipped with the snapshot
(or embedded into the binary).
My main motivation for these conversions is that we can generate
faster calls and jumps to (embedded) builtins callees from (embedded)
builtin callers. Instead of going through the builtins constants table
indirection, we can simply do a pc-relative call/jump.
This also unlocks other refactorings, e.g. removal of
CallRuntimeDelayed.
TBR=mlippautz@chromium.org
Bug: v8:6666
Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
Reviewed-on: https://chromium-review.googlesource.com/1044245
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53027}
On arm64, we had {RegisterBase::bit} (defined in assembler.h) and
{CPURegister::bit} (defined in assembler-arm.h). {CPURegister} inherits
from {RegisterBase}. The two methods methods have different
behaviour on the special {no_reg}, which is only relied on in very few
places.
This CL fixes these places to avoid the use of {no_reg}, and removes
the overwritten method.
R=mstarzinger@chromium.org
CC=rodolph.perfetta@arm.com
Change-Id: I859cc0d4ffc48fae018ee262f3e5403774db87a8
Reviewed-on: https://chromium-review.googlesource.com/1042188
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Rodolph Perfetta <rodolph.perfetta%arm.com@gtempaccount.com>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52977}
This includes the following changes:
- Limit code space to 128 MB.
- Use direct branches wherever possible.
- Where not possible, continue using load literal followed by an indirect
branch.
- Sort RelocInfo by target_address_address for the serializer, since mixing
load literal instructions and branch instructions messes up that order.
- Ensure we always wipe out targets in the serializer (not just for the
snapshot) in order to be able to distinguish between constant pool entries
and branch instructions.
Change-Id: I1a1029ce2a5f72a3a94802daf267d14a42c7c790
Reviewed-on: https://chromium-review.googlesource.com/939175
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#52885}
This is a reland of 4d7ad46db4
Original change's description:
> Introduce CodeReference
>
> Add a struct CodeReference that can be stack allocated to pass a
> reference to either an on-heap code object or off-heap WasmCode object
> in a gc safe manner. The struct also provides a common interface such
> that code can be written independently of the kind of code object it
> references.
>
> Change-Id: I5a6f74462e6e141d167c7fd9bac8c21941fd83b1
> Reviewed-on: https://chromium-review.googlesource.com/977905
> Commit-Queue: Stephan Herhut <herhut@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52580}
Change-Id: I40861474fe4a3efd72e6c59e2e7b847ab6772735
Reviewed-on: https://chromium-review.googlesource.com/1013939
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52665}
The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
This reverts commit 4d7ad46db4.
Reason for revert: Makes i18n bot red
https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_-_noi18n_-_debug%2F20162%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FAssemblerIa32JumpTabl..%2F0
Original change's description:
> Introduce CodeReference
>
> Add a struct CodeReference that can be stack allocated to pass a
> reference to either an on-heap code object or off-heap WasmCode object
> in a gc safe manner. The struct also provides a common interface such
> that code can be written independently of the kind of code object it
> references.
>
> Change-Id: I5a6f74462e6e141d167c7fd9bac8c21941fd83b1
> Reviewed-on: https://chromium-review.googlesource.com/977905
> Commit-Queue: Stephan Herhut <herhut@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52580}
TBR=mstarzinger@chromium.org,herhut@chromium.org
Change-Id: I9c49da9ee97e7423284e58bec3fdc1d212ff1af0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1010544
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52582}
Add a struct CodeReference that can be stack allocated to pass a
reference to either an on-heap code object or off-heap WasmCode object
in a gc safe manner. The struct also provides a common interface such
that code can be written independently of the kind of code object it
references.
Change-Id: I5a6f74462e6e141d167c7fd9bac8c21941fd83b1
Reviewed-on: https://chromium-review.googlesource.com/977905
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52580}
The prologue checks if optimized code exists, and if not, continues
execution of the current function. Otherwise, it jumps to the address
specified in the native module's code_table.
Also-by: clemensh@chromium.org
Change-Id: If3e76de02115f44ab7758590a949c3f0965a11ca
Reviewed-on: https://chromium-review.googlesource.com/985837
Commit-Queue: Kim-Anh Tran <kimanh@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52471}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
R=mstarzinger@chromium.org
Change-Id: Ia35a3ce91a8f6135767fa764e185cde8bbc889f4
Reviewed-on: https://chromium-review.googlesource.com/997932
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52436}
This reverts commit 57bf0bfefb.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Merge the WasmContext into WasmInstanceObject
>
> This change makes lifetime management of WasmCode much simpler.
> By using the WasmInstanceObject as the context for WASM code execution,
> including the pointer to the memory base and indirect function tables,
> this keeps the instance alive when WASM code is on the stack, since
> the instance object is passed as a parameter and spilled onto the stack.
> This is in preparation of sharing the code between instances and
> isolates.
>
> Bug: v8:7424
>
> Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
> Reviewed-on: https://chromium-review.googlesource.com/958520
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52361}
TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7424
Reviewed-on: https://chromium-review.googlesource.com/995418
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52364}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
Reviewed-on: https://chromium-review.googlesource.com/958520
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52361}
This is a follow-up to https://chromium-review.googlesource.com/981687.
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires the use of the `address_of_real_stack_limit` external
reference.
This reference is thread local, so if it is not relocated the stack
overflow check will always fail.
Bug: chromium:808848
Change-Id: I0edf3fe5a006242fc50d0bff44cd9dd0e7d85bd9
Reviewed-on: https://chromium-review.googlesource.com/982906
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52330}
This is a reland of 25207bf8cb
Original change's description:
> Remove isolate.h include from external-reference.h
>
> This triggers a bunch of other necessary include tweaks for files that
> used to work until now because they indirectly included isolate.h
> through external-reference.h.
>
> Bug: v8:6666
> Change-Id: I8d48db44dcc321fa32a6279f3ddacb41ab58f975
> Reviewed-on: https://chromium-review.googlesource.com/972042
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52103}
TBR=petermarshall@chromium.org
Bug: v8:6666
Change-Id: Ibbcf2c116dc3b202d325fd7644e8755ffe583ef1
Reviewed-on: https://chromium-review.googlesource.com/973062
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52108}
This reverts commit 25207bf8cb.
Reason for revert: Mips compile failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/16061
Original change's description:
> Remove isolate.h include from external-reference.h
>
> This triggers a bunch of other necessary include tweaks for files that
> used to work until now because they indirectly included isolate.h
> through external-reference.h.
>
> Bug: v8:6666
> Change-Id: I8d48db44dcc321fa32a6279f3ddacb41ab58f975
> Reviewed-on: https://chromium-review.googlesource.com/972042
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52103}
TBR=jgruber@chromium.org,petermarshall@chromium.org
Change-Id: I2e867d3c82b020b4fd5201aaa5cf6ed65b081ca2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/973061
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52104}
This triggers a bunch of other necessary include tweaks for files that
used to work until now because they indirectly included isolate.h
through external-reference.h.
Bug: v8:6666
Change-Id: I8d48db44dcc321fa32a6279f3ddacb41ab58f975
Reviewed-on: https://chromium-review.googlesource.com/972042
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52103}
On {mips,mips64,ppc,s390}, target addresses are specially coded into
the instruction stream, i.e. split between a series of instructions.
This adds support for that case, similar to what happens with runtime
external references.
Bug: v8:6666,v8:7571
Change-Id: Ie6f62bc0ca3183f005d8380f6f8b908fa12ea62b
Reviewed-on: https://chromium-review.googlesource.com/970824
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52091}
This is a reland of f1b1ec70a6
Original change's description:
> [builtins] Remove off-heap builtins from the snapshot
>
> This CL is the final major step towards shipping off-heap-safe builtins
> embedded into the binary.
>
> Prior to snapshot serialization, we now:
> * create the embedded blob containing off-heap instruction streams,
> * use that to generate embedded.cc (containing embedded binary data),
> * replace off-heap-safe builtins with trampolines,
> * and serialize those into the final snapshot.
>
> The new RelocInfo::OFF_HEAP_TARGET kind is used to fix up trampoline
> targets on deserialization.
>
> Bug: v8:6666
> Change-Id: Ib07aea9e3bd7ecdec42291c1388b3a7453ea96ce
> Reviewed-on: https://chromium-review.googlesource.com/950775
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51960}
TBR=yangguo@chromium.org,mstarzinger@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_mac64_dbg,v8_mac64_rel
Bug: v8:6666
Change-Id: Id9954af3c8195754ff3658c4603858904fcf88c4
Reviewed-on: https://chromium-review.googlesource.com/964481
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52006}
This reverts commit f1b1ec70a6.
Reason for revert: Tentative revert for https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8.fyi%2FV8-Blink_Mac%2F13696%2F%2B%2Frecipes%2Fsteps%2Fwebkit_unit_tests%2F0%2Fstdout
Original change's description:
> [builtins] Remove off-heap builtins from the snapshot
>
> This CL is the final major step towards shipping off-heap-safe builtins
> embedded into the binary.
>
> Prior to snapshot serialization, we now:
> * create the embedded blob containing off-heap instruction streams,
> * use that to generate embedded.cc (containing embedded binary data),
> * replace off-heap-safe builtins with trampolines,
> * and serialize those into the final snapshot.
>
> The new RelocInfo::OFF_HEAP_TARGET kind is used to fix up trampoline
> targets on deserialization.
>
> Bug: v8:6666
> Change-Id: Ib07aea9e3bd7ecdec42291c1388b3a7453ea96ce
> Reviewed-on: https://chromium-review.googlesource.com/950775
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51960}
TBR=yangguo@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org
Change-Id: I58dd4bf9a99d37416855b48807150e1dd9ecd9e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/964363
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51962}
This CL is the final major step towards shipping off-heap-safe builtins
embedded into the binary.
Prior to snapshot serialization, we now:
* create the embedded blob containing off-heap instruction streams,
* use that to generate embedded.cc (containing embedded binary data),
* replace off-heap-safe builtins with trampolines,
* and serialize those into the final snapshot.
The new RelocInfo::OFF_HEAP_TARGET kind is used to fix up trampoline
targets on deserialization.
Bug: v8:6666
Change-Id: Ib07aea9e3bd7ecdec42291c1388b3a7453ea96ce
Reviewed-on: https://chromium-review.googlesource.com/950775
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51960}
This removes the relocation mode and code specialization for table
sizes. These are now stored in the context and not inlined into code.
Bug: v8:7549, v8:7424
R=mstarzinger@chromium.org
Change-Id: I4cec78fdd365cd0c1dab9f5f4b40ffb69f540bda
Reviewed-on: https://chromium-review.googlesource.com/962221
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51926}
Keep track of RelocInfo::Mode for ConstantPoolEntries in the assembler,
so that ARM's constant pool de-duping does not accidentally dedupe
constants with the same value but different reloc modes (e.g. the first
Code object in the builtins table as a CODE_TARGET vs. the builtin table
itself as an EXTERNAL_REFERENCE).
Change-Id: I15fad5b83bb99688726e66e0e290149025c6c059
Reviewed-on: https://chromium-review.googlesource.com/958864
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51900}
This is a move-only CL (except includes cleanup).
Bug: v8:6666
Change-Id: I28422b4a21074e642e8d5c9b3a563ecafdafbda7
Reviewed-on: https://chromium-review.googlesource.com/957087
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51838}
Several cleanups:
- unify identical macro defintions
- use existing macros instead of duplicating the code
- add AVX versions for xorps and xorpd (to be used by Liftoff)
R=mstarzinger@chromium.org
Bug: v8:7310, v8:6600
Change-Id: Id37c58cf6187533ad9d4a0ca8bc5d49f9de66785
Reviewed-on: https://chromium-review.googlesource.com/937124
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51597}
The Operand class is small enough to be efficiently passed by value.
This saves binary size and performance because the Operand does not need
to be emitted to the caller's frame and loaded in the callee.
Binary saving is 37kB in release mode on ia32.
R=mstarzinger@chromium.org
Bug: v8:7310
Change-Id: Ibc103622ec216725c762c2ba4bb96451c99db556
Reviewed-on: https://chromium-review.googlesource.com/934264
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51555}
- Use CallCFunction to call C implementation of copying elements for
slice, instead of Runtime call
- Copy elements without allocating handles when copying different types
of typed arrays
Bug: v8:5929
Change-Id: Icd4fed8846542e71b623e600ba9aaac64062f0d4
Reviewed-on: https://chromium-review.googlesource.com/920563
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51415}
set constant_pool_ to proper value before trying to print it
Change-Id: Iee0da126dd3641f40c1d1847e7f1ef5d6e3e58fd
Reviewed-on: https://chromium-review.googlesource.com/916890
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51292}