Goal of this CL: explicit return from non-async function has position after
return expression as return position (will unblock [1]).
BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
If one of these methods is called then next generated bytecode will get passed
position. It's general treatment for most cases.
Unfortunately it doesn't work for Returns:
- debugger requires source positions exactly on kReturn bytecode in stepping
implementation,
- BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
generates more then one bytecode and general solution will put return position
on first generated bytecode,
- it's not easy to split BuildReturn function into two parts to allow something
like following in BytecodeGenerator::VisitReturnStatement since generated
bytecodes are actually controlled by execution_control().
..->BuildReturnPrologue();
..->SetReturnPosition(stmt);
..->Return();
In this CL we pass ReturnStatement through ExecutionControl and use it for
position when we emit return bytecode right here.
So this CL only will improve return position for returns inside of non-async
functions, I'll address async functions later.
[1] https://chromium-review.googlesource.com/c/543161/
Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
Reviewed-on: https://chromium-review.googlesource.com/560738
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46687}
v8 now uses the same SDK as Chromium, even when built as a standalone project.
The deployment target override has no effect.
Bug: chromium:740693
Change-Id: I089f74d5ad1590ff7167564f83b0110620a92ef9
Reviewed-on: https://chromium-review.googlesource.com/565887
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46686}
Changes the ShouldUseFullCodegen to use the flags on the literal instead
of the SharedFunctionInfo. Also moves the setting of the SFI flags based
on the literal to be in the final stage of unoptimized compilation since
they are no longer needed on the SFI during compilation. This is in
preparation to enable shared function infos to be created after
bytecode generation (to enable off-thread bytecode generation).
BUG=v8:5203, v8:6409
Change-Id: I15754979a704123b56dad9e1dfd5c3bb468b85c7
Reviewed-on: https://chromium-review.googlesource.com/570249
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46684}
SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.
As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:
- Modification of MacroAssembler AssertGeneratorObject. No longer
accepts a SuspendFlags parameter to determine which type of check to
perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
AccessBuilders associated with the [[await_input_or_debug_pos]] field
in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
prevent the need for the other SuspendFlag values.
BUG=v8:5855
TBR=bmeurer@chromium.org
Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
Returning a double from ToFloat64 could lead to problems. If value_ has the bit
representation of a signaling NaN (sNaN), then returning it as double can cause
the signaling bit to flip, and value_ is returned as a quiet NaN (qNaN).
The usage of the Double wrapper also, makes the function ToFloat64AsInt
redundant, since the Double wrapper already has the AsUint64() method,
which returns an uint64_t.
R=ahaas@chromium.org
Change-Id: I1e627b97b2fb6110fc702fe58f2b83eb343e9ca2
Reviewed-on: https://chromium-review.googlesource.com/563215
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46680}
This is a reland of 5648aad553.
Previous compile error should be fixed by disabling strict aliasing
assumptions on gyp: https://chromium-review.googlesource.com/c/571806
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org
Bug: chromium:610330
Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
Reviewed-on: https://chromium-review.googlesource.com/570578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46679}
In gn, strict aliasing is disabled anyway. Enabling it for gyp can cause
the compilation to fail on bots that still use gyp, or (even worse) can
lead to miscompilation because the compiler exploits strict aliasing
assumptions.
R=machenbach@chromium.org
Bug: chromium:628560
Change-Id: Ib756b8126a10d52f8c807ceda42dfc6dbda80ea6
Reviewed-on: https://chromium-review.googlesource.com/571806
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46678}
We should never try to compile unoptimized code for a function with
AsmWasm data, since it either shouldn't have been created, or should be
cleared before we reach here, so remove the check.
Also change the check for optimizing using bytecode to be a check on
whether the function HasBytecode.
BUG=v8:5203, v8:6409
Change-Id: I472b123bb370f7929555e6162af02173834d01a1
Reviewed-on: https://chromium-review.googlesource.com/569969
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46677}
Bug: v8:6000
Change-Id: I8c068383300ba869a87f836504c84ea08fcff87e
Reviewed-on: https://chromium-review.googlesource.com/568307
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46675}
This is to compare the the no-snapshot build to the
snapshot build when creating an isolate or context.
R=jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I503cde560b7897b945b3f9d2b445d0abcbfb5b60
Reviewed-on: https://chromium-review.googlesource.com/571744
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46674}
- Add more conformance tests for proxy call and calling undetectable
- This improves the performance of calling a proxy by ~5x
Bug: v8:6558, v8:6557
Change-Id: I5fe78d7ca703cfe86a2a14e39f0b6d88bb8c8e03
Reviewed-on: https://chromium-review.googlesource.com/570023
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#46673}
This reverts commit 20d5048a6f.
Revert "[heap] Ensure that concurrent marking tasks exit before heap tear down."
This reverts commit 387f65d41a.
Reason: concurrent marking tasks waiting for a signal from the main thread
is susceptible to deadlocks. We should instead re-schedule concurrent marking
threads once they exit.
BUG=chromium:694255
Change-Id: I20db2f26b42e960f4cc04506d9598c1187b8a003
Reviewed-on: https://chromium-review.googlesource.com/571800
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46671}
This fixes a refactoring bug in the AstPrinter to actually print the
try-block of {TryCatchStatement} and {TryFinallyStatement} nodes.
R=neis@chromium.org
Change-Id: I6448251c1eed3f85100902592a76dc7d3a614334
Reviewed-on: https://chromium-review.googlesource.com/571748
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46670}
The affected passes are part of OptimizeGraph which runs on a background
thread, so they must not access the heap (cast has a SLOW_DCHECK that
looks at the object's type).
I'm also changing Handle<T>::cast to assert that it's called in a scope
allowing handle dereference.
R=mstarzinger@chromium.org
Bug:
Change-Id: Ibae1e40ec8d57481387570c658eb7cb1ae5de3b9
Reviewed-on: https://chromium-review.googlesource.com/570403
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46667}
This includes several changes. From most to least interesting:
- No longer implement AwaitExpressions using a do-expression.
- Reduces frame-size of async generators by not allocating temporary
variables to hold results of Await epxressions.
- Streamline and reduce generated bytecodes for Await.
- Debugger no longer emits a debug::kCallBreakLocation breakpoint for
the JS-builtin call performed for Await, and instead only emits such
a breakpoint if the operand of Await is actually a call.
- Push fewer parameters to Await* builtins, using the receiver for the
first parameter (possible now that the CallRuntime invocation not
part of the AST).
- Adds a new Await AST node. No new members or anything, but it seemed
palatable to avoid having `if (is_await())` in a number of
VisitSuspend functions.
BUG=v8:5855, v8:5099, v8:4483
R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.orgTBR=bmeurer@chromium.org
Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
Reviewed-on: https://chromium-review.googlesource.com/558806
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46666}
The code was already there, but there was a bug in it: Because of the
missing reference, we were only updating a *copy* of the signature map,
hence the update had no effect.
This intentially is a minimal CL, in order to allow for easy
backmerging.
More mitigations and tests are coming in a separate CL.
R=titzer@chromium.org
Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c
Reviewed-on: https://chromium-review.googlesource.com/570278
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46664}
The "test-disasm-arm64/DISASM_debug" test would fail on hardware because we
expected a "hlt" instruction instead of "brk". The former is specific to running
inside the simulator.
Bug:
Change-Id: I7a5a3d4c1a93d03bbf4c934037c565d27379c2b5
Reviewed-on: https://chromium-review.googlesource.com/570442
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46663}
This is to make debugging serialization easier by having a way
to inspect the object graph. Serializer::PrintStack() can be
invoked from the debugger to print the current traversal path.
R=jgruber@chromium.org
Change-Id: Ie67408ade7989dc559904821b3f009fdfe3e459f
Reviewed-on: https://chromium-review.googlesource.com/571219
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46662}
The new message lets us know which directory is involved and what we can
do to fix it.
Bug:
Change-Id: Icfcb92b35b1ef2644649789b1e8473cb6ae50336
Reviewed-on: https://chromium-review.googlesource.com/571702
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46659}
Bug: v8:6000
Change-Id: Ia50108ebbf838e210d95cb268858394e6a66c88d
Reviewed-on: https://chromium-review.googlesource.com/567990
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46658}
It is not clear why we need this BuildTranslation. The intent of
this commit is to check if any tests fail.
Bug:
Change-Id: Ibc8a0914a1483138cfb6234e0fdf87acc0681408
Reviewed-on: https://chromium-review.googlesource.com/567922
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#46657}
Currently every VirtualMemory allocation on 64-bit systems
uses a random 46-bit address hint for ASLR.
This leads to wired page leak on MacOS discovered by Erik Chen (see
crbug.com/700928 and https://chromium-review.googlesource.com/c/557958/):
"The Darwin kernel [as of macOS 10.12.5] does not clean up page directory
entries [PDE] created from mmap or mach_vm_allocate, even after
the region is destroyed. Using a virtual address space that is too large
causes a leak of about 1 wired [can never be paged out] page per call to
mmap(). The page is only reclaimed when the process is killed."
This patch changes VirtualMemory to accept the hint parameter explicitly.
On MacOS the hints are confined to 4GB contiguous region. Algorithm:
- On startup, set heap.mmap_region_base_ to a random address.
- For each mmap use heap.mmap_region_base_ + (random_offset % (4*GB)).
BUG=chromium:700928
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2ae6a024e02fbe63f940105d7920b57c19abacc6
Reviewed-on: https://chromium-review.googlesource.com/558876
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46656}
This CL inlines the following builtins into TurboFan
- %MapIteratorPrototype%.next
- %SetIteratorPrototype%.next
following the design that we are using for Array iteration already
(different instance types for the different kinds of iterators). Details
can be found in the relevant design document at:
https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8
The key to great performance here is to ensure that the inlined code
allows escape analysis and scalar replacement of aggregates to remove
the allocations for the iterator itself as well as the iterator results
and potential key/value arrays in the simple case of a for-of loop (and
by extension also in other constructs that reduce to for-of loops
internally), i.e.:
const s = new Set;
// ... do something with s
for (const x of s) {
// ...
}
Here the for-of loop shouldn't perform any allocations of helper
objects.
Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more
general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also
migrate the {Map,Set}.prototype.size getter inlining to the
JSBuiltinReducer, so that everything is in a single place.
R=jgruber@chromium.org
Bug: v8:6344, v8:6571, chromium:740122
Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d
Reviewed-on: https://chromium-review.googlesource.com/570159
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46655}
Only allow BindingIdentifier in BindingRestPattern and
ValidReferenceExpression in AssignmentRestPattern.
Also updated to a better, actionable error message.
Bug: v8:6500, v8:6513
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ifaba2f85c20bc20e263267e8c76d50a27075b87d
Reviewed-on: https://chromium-review.googlesource.com/550559
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46653}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
Commit f37d726435 limited inner function
parsing to function declarations, to allow function expressions to
be eagerly-compiled if the parser discovered that they are immediately
invoked. But it's not only declarations that won't be immediately invoked:
methods and accessors are in the same boat, and should be treated the same.
This patch reverses the logic to exclude function expressions from inner
lazy treatment, thus making both function declarations and methods/accessors
inner-lazy-parseable.
Bug: v8:5501
Change-Id: I71a57667e52fcb917362ba629667c4c84ae29011
Reviewed-on: https://chromium-review.googlesource.com/569180
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46650}
We only optimize functions which are already compiled, so there is no need
to ensure baseline in pipeline.cc, and since ast-graph-builder doesn't
do inlining, there are no other uses.
BUG=v8:5203, v8:6409
Change-Id: I830c8868d50363f61193a96d9a5774e059a1af0e
Reviewed-on: https://chromium-review.googlesource.com/570033
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46649}
These are no longer necessary since we only have one optimizing compiler.
Also avoid changing --turbo-filter when --no-opt is set, and instead
explicitly check both the FLAG_opt and FLAG_turbo_filter in
GetOptimizedCode to check whether optimization is disabled.
BUG=v8:6408
Change-Id: I0948f788e8ff111c08022270d86c22f848da300a
Reviewed-on: https://chromium-review.googlesource.com/568484
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46648}
The WhichPowerOf2 function now takes arbitrary integer arguments, and
hence subsumes the WhichPowerOf2_64 function.
R=mstarzinger@chromium.org
Change-Id: I0692a17bbbe0074425d7c330342bc6fa34fb9d5c
Reviewed-on: https://chromium-review.googlesource.com/568495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46646}
Found issue with BuildChangeEndianness. There is difference between load and store case.
Load depends primarily on MachineRepresentation, while store depends on ValueType.
TEST=wasm-spec-tests/tests/endianness
TEST=wasm-spec-tests/tests/memory
TEST=wasm-spec-tests/tests/memory_trap
Bug:
Change-Id: I437f611107daad2f425a67fcc068e874822e0f58
Reviewed-on: https://chromium-review.googlesource.com/558882
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46645}
In my previous CL, I completely disabled the processing of inlining stacks
when generating code comments. This CL restores the feature at least for
runs without concurrent recompilation.
In other words, if you use --code-comments and want to see nice source positions,
you must also use --no-concurrent-recompilation.
Bug: v8:6048
Change-Id: Ief7e52a4046cb74e02b1783dbace19534093c588
Reviewed-on: https://chromium-review.googlesource.com/570021
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46643}
This also makes sure 6.0 and 6.1 have the same constants exposed
in v8.h.
Bug: v8:6592
R=bmeurer@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3afc0e5e4495594c76229555aab148ac78388f80
Reviewed-on: https://chromium-review.googlesource.com/569618
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46642}
In debug mode (SLOW_DCHECK), Handle<T>::cast accesses the object to
check its type. Obviously we can no longer do that now that we run
on a background thread.
NOTE: I think there are other parts of TF that suffer from the same
problem. I will look into fixing those as well.
Bug: v8:6048, v8:6590
Change-Id: I9abfdf30f1899cdb0c8b9078b0cf71463d608251
Reviewed-on: https://chromium-review.googlesource.com/570054
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46641}
This is the x64 implementation of the CL
https://codereview.chromium.org/2763593002
Original message:
[wasm][arm] Add an additional stack check for functions with big frames.
Stack overflow checks are typically implemented as part of the TurboFan
graph of a function. This means that the stack check code is executed
after frame construction. When a frame is too big, though, there may not
be enough space on the stack anymore to throw the stack overflow
exception after frame construction. With this CL we do an additional
stack check before frame construction for functions with big frames.
As discussed offline with mstarzinger, I do this change currently only
for WebAssembly.
This CL contains only the changes for arm. I will do the other platforms
in separate CLs.
R=titzer@chromium.org
Bug: v8:6318
Change-Id: Id4a8ea3ee76c37132e86a7c4e5d05d3bd86df44a
Reviewed-on: https://chromium-review.googlesource.com/565562
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46640}
... that have computed name and/or require home object.
This should give us the opportunity to implement initialization
of name and home object values in a stub.
Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I47a1a2c185e120e86c793733cce737811f895291
Reviewed-on: https://chromium-review.googlesource.com/512802
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46638}
