This simplifies integration with Bazel workspaces that already
have those libraries imported under different repository names.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: Iee6dee1abb8fca10f6b998b2ec9f459c14376bc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3333633
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78552}
This allows other Bazel projects to use their existing zlib import,
and only pull compression utils from Chromium's zlib.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: I1f88632dd07661312aa2aaf8716c1742c1f29c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375479
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78551}
This allows other Bazel projects to fetch those dependencies
without relying on a full "gclient" checkout.
Added "com_googlesource_chromium" prefix to repository names to
indicate that those are Chromium forks and not official releases.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: I87272c3e8c28d14d8974cea144e457713c59d994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375478
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78550}
The enablement of PAC in Chromium will have two phases where support
will first be enabled on C++ code (e.g. Blink/Chrome/etc) and its
dependencies, followed next by support for dynamic code generated by
V8.
This change will allow enable PAC support for C++ code when V8
is built with Chromium.
Bug: chromium:919548
Change-Id: I8ebcbcfe3c2a3a38807b814f936272ac09625795
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372162
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78548}
This reverts commit fbcdb28178.
Reason for revert: New test fails for multiple (concurrent) isolates: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/45152/overview
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
> Change-Id: I465e31e5422fa45163256be0e6594045865f0174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78545}
Bug: v8:12281
Change-Id: If0e327d02e8257a4d1cfcf8b82381af11f28e91c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377126
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78546}
The serialization format contains one boolean flag per function which
specifies whether the function code exists in the serialized module or
not. With this CL, this boolean flag is extended to a three-value flag
which indicates whether the function exists, and if not, whether the
function was executed before serialization. This information can then be
used upon deserialization to compile only those functions that were
executed before serialization.
Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
Bug: v8:12281
Change-Id: I465e31e5422fa45163256be0e6594045865f0174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78545}
This CL takes advantage of the P9 `vector byte-reverse`
instruction to implement Simd LoadSplat opcodes.
We will need to implement the rest of the `load transform` ops
before enabling this from wasm-compiler on BE machines.
Change-Id: I094e37d3b15e0dc04484eb2a701cb479f18e2f9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3371790
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78544}
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.
So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).
On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
LocalFactory::AllocateRaw() only allows the kOld and kSharedOld
allocation types, but NewArrayList() calls NewFixedArray() without
an explicit allocation argument, which then defaults to kYoung.
Add an allocation argument to NewArrayList() with the same default
value as for NewFixedArray() and pass kOld when calling it from
NewScriptWithId() to avoid tripping the DCHECK with LocalFactory.
Follow-up to https://crrev.com/c/3211575
Bug: chromium:1244145
Change-Id: I88d394bda250c45bf49141b78c09f6ca4a61dbe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354087
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78540}
The special symbols defined in heap-symbols.h were extracted out of
src/heap/heap.{cc,h} a long time ago because they logically belong to
the objects and not to the implementation of the GC/heap, so they should
have the same ownership as the objects that use them in src/objects.
Bug: none
Change-Id: I9a87c1600dc26b0fc5e620a13d409fb9116235e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375546
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78539}
We should only check the "SIMD sibling" register if we are handling a
SIMD register. This avoids unneeded spills, and in this particular case
ran into a DCHECK because there are only 29 registers, but we tried
checking #29.
R=thibaudm@chromium.org
Bug: v8:12330, v8:1285007
Change-Id: Ife8b295ac958990611ca8816bbfbfb5124a4297d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372916
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78532}
Tested with both GCC and Clang on s390x (under QEMU).
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: Iad6609136e25a6e94d51f365e4c54e6f042aa897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3346395
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78531}
This is a reland of be6bd4f448.
The reason for revert was two bots timing out. On further inspection,
the timeouts seem unrelated.
Original change's description:
> [wasm] Fast paths in EvaluateInitExpression
>
> We add fast paths for the most common types of expressions in
> {EvaluateInitExpression} to improve instantiation time. We fall back to
> full expression decoding for less common operators, or for expressions
> with operands.
>
> Bug: chromium:1284557
> Change-Id: I39a1816176974058b801cdad6eaaa6da156cea04
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367627
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78497}
Bug: chromium:1284557
Change-Id: I209458c1fa36ae41899434b90759ebe3fe5e2a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375545
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78529}
Without the comma, the two strings '--no-enable-sse3' and
'--noenable-ssse3' will be concatenated, resulting in missing detection
for the no_simd_hardware flag.
R=liviurau@chromium.org
Bug: v8:12521
Change-Id: Icbdc5e8057d1eeead472f76efd52c379bffbe5b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372914
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78528}
Inlining the field accesses make the code simpler by avoiding the
abstraction of the accessor, and makes stepping through the code for
debugging easier.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I51bd0e88baa5ffba5bd4bfcca36e95caab7468c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372913
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78521}
Since the accessors are only called from other methods in the same
class, we can just access the field directly. This makes stepping
through easier and makes the code simpler by avoiding an unneeded
abstraction.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I39727324e82fcfd15b3b242c53ed5534e2e5511d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372912
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78520}
This should have been updated in https://crrev.com/c/3370408
Bug: chromium:1284506
Change-Id: Ie44d80b507c9a798ce6f4776672270f9d4b12195
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3371463
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78519}
The test was added in https://crrev.com/c/3372910, but needs to be
skipped on non-SIMD hardware because it contains SIMD instructions.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Ifaede466b24aea4f9ef6b062414a31698bcca864
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372917
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78517}
The register state is accessed a lot in the mid-tier register allocator.
Instead of going through an accessor with a DCHECK, just access
directly. This makes stepping for debugging a lot easier, and will
result in an easy-to-debug nullptr access if the register state is not
initialized.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: Icf4d1cc187a34f28ee44fc9b80ee5d765aa14b9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372911
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78516}
The bailout is there explicitly in the code, so we should allow it in
{CheckBailoutAllowed}.
R=ahaas@chromium.org
Bug: v8:12527
Change-Id: Ifd906afb5f034f05c2bf7d9a28e3ab458549e7ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372915
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78515}
Spilling was already fixed if a fixed SIMD register overlaps with an
allocated FP register, but the other way around was missing: If an odd
FP register (in this case d1) is used as a fixed output register, but
this register is in use as the upper half of a SIMD register (in this
case q0), we did not detect this and would just use overwrite the SIMD
half.
This CL also fixes this case.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Id3f98b7accd77e38ab4cd5ff8910aaf5ad96a1ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372910
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78514}
Rolling v8/build: f29e3b6..3fd1fd5
Rolling v8/buildtools/linux64: git_revision:19bf826e6e5d05100cb3568e90e48bd3c97d4f22..git_revision:387b368dfe63fec317f8e609d90c634807f2764e
Rolling v8/buildtools/third_party/libunwind/trunk: 6a10e3e..4bf418e
Rolling v8/third_party/depot_tools: e971498..9552069
Rolling v8/tools/clang: 24c1100..17ca796
Rolling v8/tools/luci-go: git_revision:89429843eb2dedb599a6c7c7754343b97d95943d..git_revision:d1e877e2b3e5a05a5cd34c4a340fedba14a16c2b
Rolling v8/tools/luci-go: git_revision:89429843eb2dedb599a6c7c7754343b97d95943d..git_revision:d1e877e2b3e5a05a5cd34c4a340fedba14a16c2b
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I9b882395fb44b11308a3e55166bbf7f527c538d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3371705
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78508}
https://crrev.com/c/3297708 changed the serialization format for typed
arrays without bumping the format version. As a consequence, builds that
include that CL fail to deserialize typed arrays serialized by previous
V8 versions.
This CL reverts the serialization format change, and does minimal test
changes to reflect the revert. https://crbug.com/v8/12532 tracks
serializing typed array flags in a backwards-compatible manner.
Bug: chromium:1284506
Change-Id: Ib32e88c6383e0ad4ad1a9ff63f413a1eb123b1ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3370408
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78507}
Rolling v8/build: ccc9811..f29e3b6
Rolling v8/buildtools/linux64: git_revision:281ba2c91861b10fec7407c4b6172ec3d4661243..git_revision:19bf826e6e5d05100cb3568e90e48bd3c97d4f22
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ec88714..aa0e8d0
Rolling v8/third_party/depot_tools: 02d65ea..e971498
Rolling v8/tools/clang: 2d10229..24c1100
Rolling v8/tools/luci-go: git_revision:e897e118887a2e6c50a82212b660cb2a7c58d910..git_revision:89429843eb2dedb599a6c7c7754343b97d95943d
Rolling v8/tools/luci-go: git_revision:e897e118887a2e6c50a82212b660cb2a7c58d910..git_revision:89429843eb2dedb599a6c7c7754343b97d95943d
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I9d02d870a7233878220336aaa985c9216f521c58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3362608
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78505}
In the C++20 a following paper was implemented [1]. This
paper makes code below illformed. The high level idea is
that as soon as class gets non default constructor - all
default initializations are not added implicitly.
class A {
public:
A(const A&) = delete;
};
int main() {
A a{};
return 0;
}
So if V8 embedder is building its code with C++20 it can
not initialize v8::CppHeapCreateParams struct and as a
result can not create a CppHeap.
One of the possible mitigations (3.3) from the paper is
to add non copyable field into class. Luckily there
is std::vector<std::unique_ptr>> in this class already.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1008r1.pdf
Change-Id: I8a2dc35784d7646b5f73a5e178716e9bf2ffe601
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3348007
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78504}
