After https://crrev.com/c/2695401, CachRegs needed to be defined
on PPC to overwrite the default value "0xff".
The default value was causing the following failure on some tests:
```
#
# Fatal error in ../../src/wasm/baseline/liftoff-register.h, line 160
# Debug check failed: 0 != kLiftoffAssemblerGpCacheRegs & reg.bit()
(0 vs. 0).
```
Values are taken from `src/execution/ppc/frame-constants-ppc.h`.
Change-Id: Idfc1d0fdc20d0b5aabc25e5b5809a93073a2dc3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698930
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72827}
This missing include was undetected because trace_perf.cc is only
built if the checkout_google_benchmark custom gclient variable is
defined.
Bug: none
Change-Id: If2016edad4df382f14903593ea18066f7759c4d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698387
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Chris Mumford <cmumford@google.com>
Cr-Commit-Position: refs/heads/master@{#72825}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72824}
This is a reland of cf93071c91
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}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
Previously, ephemerons without a base_object_payload have been
filtered. base_object_payload is currently used to differentiate
between GarbageCollected and just traceable objects, so we need to
pass on the empty descriptor.
Bug: chromium:1056170
Change-Id: I9cba53295779ec74dce2822b7bf83f477bc3241f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2700039
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72820}
Move the CompileWithBaseline interface to the Compiler class, as
CompileBaseline, which will do the additional work of pre-compiling
to bytecode, ensuring there is a feedback vector, and setting the
code on the function closure.
As a drive-by, fix v8_enable_trace_unoptimized to have a blank default
value, so that v8_enable_trace_ignition/v8_enable_trace_baseline_exec
can set it.
Bug: v8:11420, v8:11429
Change-Id: If715161de71f7d9300f3fdcbb50cc678b1fcdfdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697352
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72819}
Port af3c5307f0
Original Commit Message:
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.
R=verwaest@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I354329238d00503a234556f25adccd920d26d320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2700036
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72816}
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}
