In case there's no exact match for the breakable location in
SetBreakpoint(), don't try to find the syntactically closest break
location, but rather find the first possible break location in bytecode
order. In particular when trying to set a breakpoint in a line with
for-of or an array destruction, there's no point in going for the
syntactically closest to the beginning of the line, but rather go for
the semantically first, as the intiution for setting a breakpoint on a
line is that the debugger stops before it executes anything on said
line. In the example
```
var [^a, ^b] = ^func();
```
there are three possible break locations, and the correct one is the
last one as the call to func will happen first at runtime.
For generators that's currently broken because of the implicit initial
yield, and same with modules (see crbug.com/901819), so we keep the
previous behavior of finding the closest breakable location, and will
fix that independently in a follow up CL.
Bug: chromium:901819
Fixed: chromium:782461
Also-By: yangguo@chromium.org
Change-Id: Ie724c5cb08e5f4edd90a450d99e001dff06bbe7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72813}
Pinned registers were not considered correctly when taking a volatile
register. This CL refactors handling of the pinned registers list by
combining the candidates list and the pinned list early. This avoid
additional parameters on some functions and might save some redundant
masking.
As a side effect, it also fixes the DCHECK error on arm.
R=ahaas@chromium.org
Bug: chromium:1179025
Change-Id: Ib9193b209c5741ea97fd1d0dffeeb9e824639439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699254
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72812}
We made two runtime calls: The first one allocated the exception object
containing a FixedArray of exception values, the second call did the
actual throw. Inbetween the code was filling the values array.
This CL refactors this to only allocate the FixedArray initially, fill
it, and then allocate the actual exception and throw it both from the
second runtime function.
This avoids a WasmGetOwnProperty call to find the values array.
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: I091aaa5c7bfb2b5579fc92c953adf582e6cc175a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697359
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72811}
During the string reverts a while back
https://chromium-review.googlesource.com/c/v8/v8/+/2633547 I reverted
some tests that were testing the code that was *not* reverted i.e. the
internalization of external strings.
Bug: v8:7790
Change-Id: I84964791cce712d753fd409cc3c641d9fbbb6550
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699262
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72809}
Add baseline builtins for CreateAsyncFromSyncIterator and
GetImportMetaObject, and call those instead of the runtime functions.
Drive-by remove some TODOs in baseline-compiler.cc which are either no
longer planned or don't need to be done any time soon.
Bug: v8:11420, v8:11429
Change-Id: I15b4fe1f04316492045250b2c65ab6016f29b313
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699261
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72808}
The csuite.py script does not work correctly on Windows. It runs
correctly in baseline mode, but there are two problems when running in
compare mode:
1. In compare mode the output of benchmark.py is piped to the
compare-baseline.py script, but Windows only execute python files if
python.exe is the default program to open '.py' files, and this is
not the case, by default, when python is installed as part of the
depot_tools.
Fix: explicitly add the 'python' command before compare-baseline.py.
2. By default CSuite prints the results to stdout using escapes codes
that add color highlights. But this does not work on Windows when
compare-baseline.py is launched with a pipe:
python test/benchmarks/csuite/benchmark.py <...> |
python test/benchmarks/csuite/compare-baseline.py <baseline_results>
Fix: Do not use a pipe. Write the benchmark numbers for the
compare-run into a separate file, and pass the path to this file to
compare-baseline.py
Change-Id: Ic22d5bd4b47901f0ba0f35bc2496441346d21c6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656855
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72807}
The expected exception in this regression test is thrown due to a
limitation in the IrRegExp engine.
The experimental engine is unaffected and won't throw.
Bug: v8:11363
Change-Id: If37d86f5d4494b40c47ecc5e5bc4f86fda30389c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699251
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72806}
This threads through a JumpMode kJump/kReturn to JumpCodeObject so we
can use a return instruction to jump instead by first pushing the jump
target and then using a return instruction.
Bug: v8:11429
Change-Id: I8658ed9c5bade28bd6efc76e26fd92bad22b3c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697196
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72804}
This reverts commit e27b7b6069, which was
a workaround. The original problem is not reproducible anymore.
Bug: v8:9717
Change-Id: I11e165d7ec9643ec805ab8c075b720b58e7769bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699249
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72803}
samples being discarded
- Passed in as CpuProfilingOptions parameter, client is responsible for
determining if function is still safe to execute. Includes unit tests
- Client (blink) side CR: https://chromium-review.googlesource.com/c/chromium/src/+/2649617,
- Client (blink) side CR requires this to be pushed prior to it being pushed
Change-Id: I3ef4640186115d4e14c1b73f902c889c776e310f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652206
Commit-Queue: Nicolas Dubus <nicodubus@fb.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72794}
Port adf035fb41
Original Commit Message:
This CL avoids redundant loads of the instance from the frame by caching
it in a register if possible. This register will be the first one to be
cleared once we run out of registers (hence it's called a "volatile
register"). On local tests, this seems to reduce most redundant loads
within a function, and it also reduces the load for the stack check in
the function prologue.
After the stack check, we need to discard the cached instance though,
since the potential runtime call for the stack check might clobber it.
This will be addressed in a follow-up CL by re-loading the cached
instance after the stack check. This is expected to remove another good
chunk of instance loads, because the instance would initially be
available in a register when starting the function code.
R=clemensb@chromium.org, midawson@redhat.com, mfarazma@redhat.com
BUG=
LOG=N
Change-Id: I3756ce98d4dfefb44c946a4948f1a6dbe0ce44dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698291
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72791}
As of https://crrev.com/c/2629465, Simd tests cannot pass on
architectures without Simd support. Tests will need to be re-enabled
once Simd support is fully implemented on PPC.
Change-Id: I963639f1afa0c0ca7be3ca4b2fc06e874235b903
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2693056
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72788}
Implicitly rethrow the exception when we reach the end of a
try..unwind..end. Also make it a validation error to rethrow
an exception caught by an unwind block.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Ia149d2e81b1fbfa9209047b35ff0c9fedc1b8895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696662
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72785}
The WasmThrow and WasmRethrow runtime functions have the same signature,
but we should still use the correct description in case the signature
changes (which is planned for a follow-up CL).
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: Iaec9c353d30fa7673ceb8994e3029c4adfc01311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697348
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72784}
The Debug::SetBreakPointForScript() method essentially figures out the
SharedFunctionInfo and then duplicates the logic from SetBreakpoint().
Bug: chromium:1162229
Change-Id: Iae98ab5d182739d44e0277b799509723d950f381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697351
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72782}
- Adds DCHECKs to make sure no stack slots are allocated after
aligning a frame.
- Changes Arm64 CodeGenerator::FinishFrame to align the frame after
allocating callee-saved registers, and relaxes the constraints on
the number of callee-saved registers.
Bug: v8:9198
Change-Id: Iacb0518b57fa3ea2ff801eda69719f4c32733850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2694104
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72781}
This CL avoids redundant loads of the instance from the frame by caching
it in a register if possible. This register will be the first one to be
cleared once we run out of registers (hence it's called a "volatile
register"). On local tests, this seems to reduce most redundant loads
within a function, and it also reduces the load for the stack check in
the function prologue.
After the stack check, we need to discard the cached instance though,
since the potential runtime call for the stack check might clobber it.
This will be addressed in a follow-up CL by re-loading the cached
instance after the stack check. This is expected to remove another good
chunk of instance loads, because the instance would initially be
available in a register when starting the function code.
R=thibaudm@chromium.org
Bug: v8:11336
Change-Id: Ie65ab81263fb9d972f4b7a6daaef86cf704874ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695401
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72779}
This reverts commit cf93071c91.
Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
My previous CL was missing a negation in two places.
Bug: chromium:1178731
Change-Id: I5bc4d78226e43a62ddd374c3d7dd36a9ed0c1a2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697192
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72775}
Custom platform implementations which do not run all foreground tasks
before shutting down an isolate could trigger a DCHECK (see linked
issue).
This was introduced in https://crrev.com/c/2578980, but the bug does not
trigger in the default platform implementation, hence went unnoticed.
Since it's only a spurious DCHECK error without security implications, I
decided against a test with a custom platform implementation to
reproduce the bug.
R=ahaas@chromium.org
Bug: v8:11456
Change-Id: Ie01562af7bdffe23cad7172180f2bc19ea61dfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697189
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72774}
Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.
In order to not degrade speed, a couple of other changes are required:
The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.
A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.
Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.
Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
Baseline scratch registers don't include the regular kScratchRegister
(for now at least) because the rest of the system doesn't use the
ScratchRegisterScope (yet).
Bug: v8:11429
Change-Id: I7a2f27a814e262e5b14bd30b2ae53d53e173bcc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697194
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72771}
Lazy sweeping may have found a memory block not positioned at the head
of the corresponding bucket. Such a block is not found during a
subsequent free list allocation, as such allocations do not linearly
walk the free list.
Bug: chromium:1056170
Change-Id: I288b6ad768987705d86fc78d0aa6fe46e99417b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692822
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72770}
The current API returns a Handle<NativeContext> which can be
optionally null and all the users of this API never actually
checked for this null value.
Previously, this wasn't a problem as all the possible JSObjects
that were user visible would return a valid NativeContext but now
there are wasm objects that don't have a valid constructor so don't
have a NativeContext.
Bug: v8:11451, chromium:1166077
Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72769}
When there are multiple nested catch blocks, the rethrow immediate
disambiguates which catch block to take the exception from. We
add a FixedArray to keep track of exceptions that are currently
in scope, and compute the mappings between rethrow/catch instructions
and the index to fetch/store the exception from/to in the FixedArray
during pre-processing.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: If55242c551f42262c790b5bf3f1543a003280623
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695388
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72768}
Change the interpreter tracing functions to be generic unoptimized code
tracing functions. The type of the code is now inferred from the frame,
rather than passed in.
Also expands the set of gn flags to explicitly enable unoptimized
tracing, with a helper gn flags for enabling it for Ignition and for
baseline (both just set unoptimized tracing to be enabled for now, we
could split this up in the future though), and V8 flags separate tracing
Ignition and tracing baseline.
Bug: v8:11420, v8:11429
Change-Id: I040c2628fe5744dcb38ef8623df3e34f9c86a5b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692817
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72767}
The origin trial for WebAssembly Threads is over for quite some time,
WebAssembly Threads are enabled by default. The API can therefore be
removed now.
Bug: v8:11384
Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72766}
Changes:
- In graph-builder-interface.cc, move loop exit utilities in the private
section.
- In the same functions, remove SsaEnv argument. Always use ssa_env_
instead.
- Introduce TerminateThrow, which introduces loop exits before inserting
a throw node.
- Introduce loop exits in the exception handling opcodes.
- Introduce control_depth_of_current_catch() helper.
- Drive-by: Add an optional missing 'break' in DoReturnCall.
- Add some tests, improve test flags in loop-unrolling.js test file.
Bug: v8:11298
Change-Id: I613352023e3e1c72a83cd389d98574758655abee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692820
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72765}
- Also changes in arm and ia32 for consistency
- Removes fall-through since MaybeOptimizeCode never returns
Change-Id: I115cff07c7d58ac3f7d0e0feeccbd6b1b172bd53
Bug: v8:11429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695392
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72764}
