This reinstates the old behavior of Error.captureStackTrace prior to
4feafee9d9. Like the builtin Error constructors, captureStackTrace now formats
the stack trace lazily once it is accessed.
Bug: v8:5962
Change-Id: I03821b73d26b7b40809a1fea98f9c820bfa05d6b
Reviewed-on: https://chromium-review.googlesource.com/574530
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46727}
Previously,
➜ v8 (master) ✔ ./out.gn/x64.optdebug/d8
V8 version 6.1.0 (candidate)
d8> var x = undefined
undefined
d8> var [a] = x
(d8):1: TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
var [a] = x
^
TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
at (d8):1:11
Now,
➜ v8 (fix-iterator) ✔ ./out.gn/x64.optdebug/d8
V8 version 6.1.0 (candidate)
d8> var x = undefined
undefined
d8> var [a] = x
(d8):1: TypeError: x is not iterable
var [a] = x
^
TypeError: x is not iterable
at (d8):1:11
Bug: v8:6599, v8:6513
Change-Id: I71287a19166af0289e8f7708b8f41ad003ae87ae
Reviewed-on: https://chromium-review.googlesource.com/571175
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46723}
This reverts commit a72b2f88a8.
Reason for revert: Breaks https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/7093
Original change's description:
> [arm] Restrict grouping pushes before a TailCall to registers only
>
> We optimize parallel moves performed before a TailCall by grouping adjacent
> pushes. This way, we may use a single instruction to push multiple registers at
> once. However, we also have support for pushing immediates and stack slots for
> which the benefit is questionnable therefore this patch removes support for
> them.
>
> Concerning immediate pushes, it looks like a mistake since we do not have
> support for this case in `AssembleMove` so this patch removes it. Furthermore,
> if we add a test for this case, we see that a `push ip` instruction is
> generated, effectively pushing whatever was in `ip` at the time instead of
> pushing a constant.
>
> Concerning stack slot pushes, we generate a more or less equivalent sequence of
> instructions.
>
> Finally, grouping floating point pushes is not used anywhere so this patch
> removes support for this also.
>
> Bug: v8:6553
> Change-Id: I9b820d33361fc442dd813f66e1f96cda41009110
> Reviewed-on: https://chromium-review.googlesource.com/567191
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
> Cr-Commit-Position: refs/heads/master@{#46718}
TBR=danno@chromium.org,jarin@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org
Change-Id: Ib9db9e6e4f033aeea32741e04b1b884429acc800
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6553
Reviewed-on: https://chromium-review.googlesource.com/574908
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46719}
We optimize parallel moves performed before a TailCall by grouping adjacent
pushes. This way, we may use a single instruction to push multiple registers at
once. However, we also have support for pushing immediates and stack slots for
which the benefit is questionnable therefore this patch removes support for
them.
Concerning immediate pushes, it looks like a mistake since we do not have
support for this case in `AssembleMove` so this patch removes it. Furthermore,
if we add a test for this case, we see that a `push ip` instruction is
generated, effectively pushing whatever was in `ip` at the time instead of
pushing a constant.
Concerning stack slot pushes, we generate a more or less equivalent sequence of
instructions.
Finally, grouping floating point pushes is not used anywhere so this patch
removes support for this also.
Bug: v8:6553
Change-Id: I9b820d33361fc442dd813f66e1f96cda41009110
Reviewed-on: https://chromium-review.googlesource.com/567191
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46718}
This is the ia32 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.
Bug:v8:6318
R=neis@chromium.org, titzer@chromium.org
Change-Id: Ibeedc5c4c4571cffd3a9c58016ddc44b64e2bf02
Reviewed-on: https://chromium-review.googlesource.com/568305
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46711}
If the incremental marker discovers more marking work and the concurrent
marking tasks have already exited, then new concurrent marking tasks
are scheduled to help the main thread marker.
BUG=chromium:694255
Change-Id: I559af62790e6034b23a412d3308ba8b6ae3d27c9
Reviewed-on: https://chromium-review.googlesource.com/574170
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46703}
This reverts commit a2fcdc7cc8.
Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
Original change's description:
> [runtime] Move profiler ticks from SFI to feedback vector
>
> Instead of counting profiler ticks on the shared function info (which is
> shared between native contexts), count them on the feedback vector
> (which is not). This allows us to continue pushing optimization
> decisions off the SFI, onto the feedback vector.
>
> Note that a side-effect of this is that ICs don't have to walk the stack
> to reset profiler ticks, as they can access the feedback vector directly
> from their feedback nexus.
>
> Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
> Reviewed-on: https://chromium-review.googlesource.com/544888
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46411}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
Reviewed-on: https://chromium-review.googlesource.com/574227
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46702}
Some of the benchmarks were pointing to the wrong test functions.
Bug:
Change-Id: I6f7850feec1da61bea7b8c1ac03c00d75400f458
Reviewed-on: https://chromium-review.googlesource.com/574023
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#46701}
There are wasm tests which are supposed to fail, but they fail for the
wrong reason (because blocks do not declare their type).
This CL fixes this, and changes the error output to contain the
expected and observed results for better debuggability.
R=titzer@chromium.org
Change-Id: Ibbd7883e43677a91f858575578586c9e9d1641d5
Reviewed-on: https://chromium-review.googlesource.com/571810
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46698}
This makes the runtime rely on the {HasBytecodeArray} predicate to
determine whether code generated by TurboFan was build without any
deoptimization support, as opposed to {asm_function}.
R=rmcilroy@chromium.org
BUG=v8:6589
Change-Id: Id124bed47a5fa02d31ff8fd3eee561b2df6c9226
Reviewed-on: https://chromium-review.googlesource.com/571786
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46694}
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}
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}
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}
- 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 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}
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}
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}
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}
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}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
Additionally, drive-by add a test inspired by a worrying TODO
in the parser.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng,master.tryserver.v8:v8_linux64_msan_rel,v8_linux64_tsan_rel,v8_linux_arm64_dbg,v8_linux_gc_stress_dbg,v8_linux_noi18n_rel_ng,v8_linux_nosnap_rel
Change-Id: I693a858a638753f8c1091f2f9086710f628b40dd
Reviewed-on: https://chromium-review.googlesource.com/553677
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46634}
This reverts commit 5648aad553.
Reason for revert: Compile error on mips:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
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,clemensh@chromium.org
Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:610330
Reviewed-on: https://chromium-review.googlesource.com/569962
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46630}
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.orgCC=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}
When disassembling some instructions we would print `r12`, which can be
confusing when the rest of the disassembly consistently uses `ip`.
Bug:
Change-Id: Id4cfc5805ef102a0845cdaaa8390e618ee981b19
Reviewed-on: https://chromium-review.googlesource.com/570038
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46628}
There is just one version now, called IsPowerOfTwo. It accepts any
integral type.
There is one slight semantical change: Called with kMinInt, it
previously returned true, because the argument was implicitly casted to
an unsigned. It's now (correctly) returning false, so I had to add
special handlings of kMinInt in machine-operator-reducer before calling
IsPowerOfTwo on that value.
R=mlippautz@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org,yangguo@chromium.org
Change-Id: Idc112a89034cdc8c03365b778b33b1c29fefb38d
Reviewed-on: https://chromium-review.googlesource.com/568140
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46627}
This CL changes the USE macro to accept more than one parameter.
This is particularly interesting for calling a method on each type in a
parameter pack, as in:
template<typename... T>
void foo(T&&... ts) {
USE(do_something(ts)...);
}
Drive-by fix: Allow to pass arbitrary types to USE, including
references. This might prevent a copy for pass-by-value.
R=ishell@chromium.org, tebbi@chromium.org
Also-by: tebbi@chromium.org
Change-Id: I544e83bb996aaa638e7512295973dd3e742254bc
Reviewed-on: https://chromium-review.googlesource.com/567507
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46626}
