It would be nice if unused {RegClass}es just equal {kNoReg} on all
platforms.
This CL adds the static asserts for that, and slightly modifies the
definition of the {RegClass} enum to fulfil that. Interestingly, this
only changes the values for the one configuration that is currently
unused :)
R=zhin@chromium.org
Change-Id: Ib1b2a663183ad34822f514d6168c65450c1d7f2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975753
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65527}
For functions which check if a register pair is used, change them from
is_gp_pair to is_pair, since they do not care if the pair of register is
a gp pair or a fp pair.
Bug: v8:9909
Change-Id: I262108caadd616c64019b39ebbf6972a548112df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1974833
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65526}
For Smi, we can avoid calling the ToNumber builtin, and also the
conversion to float and back. This adds some complexity, but greatly
improves performance for parameters that fit in a Smi.
R=jkummerow@chromium.org
Bug: v8:10070
Change-Id: Ic55f17e42ce52811296293f3cd218c850af42961
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965576
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65525}
This new API uses the code pages rather than code ranges approach.
It's supported on arm32, as well as the previous two supported
platforms, x64 and arm64.
Deprecate the old API which only works on x64 and arm64 to reduce the
maintenance overhead of keeping both. Users of the old API should
migrate to the new one as it can be used all on supported platforms.
We keep the tests for the old API by ignoring deprecation warnings so
that we don't accidentally break it while it is still in the codebase.
Design doc:
https://docs.google.com/document/d/1VGwUult5AHLRk658VetwEHMOmDDxA2eDQs9lDFMZTE0
Bug: v8:8116
Change-Id: I1de8246a48fc1b4991603501ea6087db6b43fdd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969900
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65521}
After calling the ToNumber builtin, we are guaranteed to get either a
Smi or a HeapNumber. Thus we can skip the check for undefined, which
removes quite some unneeded code from wasm-to-js and js-to-wasm
wrappers.
R=ahaas@chromium.org
Bug: v8:10070
Change-Id: I0e2ad19f1575fb6979222e324fbdb71aaf85e6fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962279
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65520}
The spec was normatively changed to simplify var scopes for parameter
expressions. Previously there was a per-parameter var scope in sloppy
mode so direct evals could introduce vars that did not escape the
parameter position. That semantics is complex both for the programmer
and implementation and has resulted in bugs in the past. Furthermore, it
has never been fully interoperable (with Safari in particular). The spec
was instead changed to be simpler: to have a single var scope for
sloppy evals in parameters that encloses the parameter scope and body
scope.
This simplification lets us remove expression-scope-reparenter.
Drive-by removal of stale reference to PatternRewriter.
Bug: v8:7532
Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65517}
Also port a few smaller functions.
Bug: v8:9838
Change-Id: I2245abe648378970a89331baa19af49f7f49359b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1961942
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65510}
This introduces a new constant kNeedS128RegPair, which is set for
architecture where a pair of FP registers (DoubleRegister) is mapped to
single Simd128Register (ARM).
In this case, a new RegClass, kFpRegPair, is defined to represent
LiftoffRegister of this type. kFpRegPair will be kNoReg on all other
architectures.
We add 1 more bit to the encoding on ARM, so now the top bit is set for
kFpRegPair, the second most top bit is set for kGpRegPair. When the top
bit is set, we encode the FP register code into the bottom bits of
code_. Note that this is directly encoded, i.e. not added to kMaxGpRegCode,
so we can save an add/subtract when converting to/from DoubleRegister.
We only need to store 1 FP register, the low register, since the high
other register is implicity the next register. Note that the stored
register is *always* an even-numbered register.
Bug: v8:9909
Change-Id: I78d603c9938c3d0add9bd3ca77ddebbfa7abbc05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973276
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65508}
In setting breakpoint in wasm, we can find wasm script from location but
in removing a breakpoint, only breakpoint id is provided. For wasm, we
have a list of all BreakPointInfo objects attached to the Script. From
breakpoint id, we iterates all scripts to find the targeted breakpoint
and remove it.
Bug: chromium:837572
Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65505}
This CL implements enums in Torque in three steps:
1.) It implements necessary changes to Torque's type system. In
particular, the constraints on constexpr types are relaxed such that
constexpr types can exist without a corresponding non-constexpr
version. Furthermore, constexpr and their non-constexpr counterpart
need not be of the same kind of type. This allows an AbstractType to
have a UnionType as its non-constexpr counterpart.
2.) The enum feature itself is realized as a pure desugaring in the
parser, where all required types, constants and macro specializations
(like FromConstexpr<>) are generated from a simple enum declaration,
such that enum entries are not just constants, but are namespace
scoped and have distinct types so that they can be used within
typeswitch constructs.
3.) Almost all of the existing constants defined in torque
(.tq files) are ported to new enum definitions.
Bug: v8:10053
Change-Id: I72426d3b1434f301fd690847e15603de0dc1021b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964392
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65503}
This is similar to the change made to IsImmLSPair in
9f7ae50aa8.
Change-Id: I17a7cc95661542efb5711df0639cc11ac7926702
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1971950
Commit-Queue: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65501}
This is a reland of c509bb8c55
Original change's description:
> Cache native modules in the wasm engine by their wire bytes. This is to
> prepare for sharing {Script} objects between multiple {WasmModuleObject}
> created from the same bytes. This also saves unnecessary compilation
> time and memory.
>
> R=clemensb@chromium.org
>
> Bug: v8:6847
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916603
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65296}
R=clemensb@chromium.org
Bug: v8:6847
Change-Id: I8839c9ec96dc4141cf3c30916a62ccf86f5463ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960287
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65500}
This reverts commit 5377e72c0e.
Reason for revert: Looks like the relevant graphs didn't recover after
this revert, which suggests that the regression was an unrelated
secondary effect. Relanding the original change since the revert did
cause some microbenchmark regressions.
Original change's description:
> Revert "[ic] Load name/context lazily in LdaNamedProperty"
>
> This reverts commit 347092ac2b.
>
> Not a clean revert, since other changes got baked on top, but rather
> a manual removal of LoadLazyICParameters.
>
> Reason for revert: Seems to actually regress bindings perf tests (see
> bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
> seem to improve performance elsewhere, and increases complexity.
>
> Original change's description:
> > [ic] Load name/context lazily in LdaNamedProperty
> >
> > Introduces LazyLoadICParameters which allow a LazyNode for context and
> > name. These aren't used on the fast path, so we want to avoid reading
> > them for both performance and register pressure reasons.
> >
> > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62539}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: chromium:981797
> Bug: chromium:982630
> Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65205}
TBR=leszeks@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:981797, chromium:982630, v8:10059
Change-Id: I13754de06c83439e03e22cfaa7a14ce454076db9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973730
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65499}
For supporting use of dictionaries during GC, such as in the JS WeakRef
implementation.
Bug: v8:8179
Change-Id: Ide3f5c45d2602f13a1bcb1968b36f08881067090
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1972427
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65498}
When V8 throws an uncaught exception, we store a JSMessageObject
with a stack trace and source positions on the isolate itself.
The JSMessageObject can be retrieved by a TryCatch scope
and is used by the inspector to provide additional information to the DevTools
frontend (besides the exception).
Introducing top-level await for REPL mode causes all thrown exceptions
to be turned into a rejected promise. The implicit catch block that does this
conversion clears the JSMessageObject from the isolate as to not leak memory.
This CL preserves the JSMessageObject when the debugger is active and stores
the JSMessageObject on the rejected promise itself. The inspector is changed
to retrieve the JSMessageObject in the existing catch handler and pass the
information along to the frontend.
Drive-by: This CL removes a inspector test that made assumptions when a promise
is cleaned up by the GC. These assumptions no longer hold since we hold on to
the promise longer.
Bug: chromium:1021921
Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65497}
Allocate memory more quickly so the test completes faster. (On the ARM
simulator tests with slow asserts and verify-heap, it was taking around
20 minutes).
Change-Id: I6b4d0a4788817c4f996a073cc3fdf8b69d11bc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973731
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65495}
Nullify is already defined in an -inl.h, so there is no need for the
extra functionality (and overhead) of std::function.
Bug: v8:8179
Change-Id: I0b149a962409503a9fde150aa1241de74870533e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1972426
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65494}
This reverts commit 9f18e55ff0.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/29660
Original change's description:
> [TurboFan] Don't serialize read-only heap objects
>
> Read-only heap objects are immutable and immovable. It is safe to access
> these objects directly from the heap. Not having to serialize them
> reduces the time we spend on main thread especially for TurboProp.
>
> Bug: v8:9684
> Change-Id: Ibabb7076af50c9007d2a8ed57fe257406958fb6a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955596
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65490}
TBR=mvstanton@chromium.org,neis@chromium.org,mythria@chromium.org,mslekova@chromium.org
Change-Id: If2d8649cdc083f7d064684352501320a96a1ba2c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973732
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65492}
This CL adds an argument to the heap profiler that allows to control
whether global objects (e.g. 'window' in JavaScript) are treated as
roots in the heap snapshot. Doing so hides blink-internal details and
is often a good choice when user-JS leaks are investigated. Sometimes,
however, this introduces spurious retainer cycles, which are hard to
debug.
Previously, this option was exposed as a V8 flag. The blink
implications of the build-time V8 flag are now available via
the new blink flag `enable_additional_blink_object_names`.
Tbr: hpayer@chromium.org
Bug: chromium:1034504
Change-Id: Ibe9412917ae598a3ff0c3dc956ab0bc179f50a21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967387
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65491}
Read-only heap objects are immutable and immovable. It is safe to access
these objects directly from the heap. Not having to serialize them
reduces the time we spend on main thread especially for TurboProp.
Bug: v8:9684
Change-Id: Ibabb7076af50c9007d2a8ed57fe257406958fb6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955596
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65490}
This change implements support for reading and writing bitfields from
Torque code, and adds a couple of unit tests for this functionality. As
Tobias suggested, the LocationReference for a bitfield access contains
a nested LocationReference to where the bitfield struct is stored, so
that store operations can read the original value, update part of it,
and write it back.
Bug: v8:7793
Change-Id: I1004a5c7fcb6cf58df5ad50109b114bf89c80efc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957841
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65487}
Add a --max-serializer-nesting flag which defaults to 25.
Fixed: chromium:1034768
Change-Id: Ib68f26ce4bf53db297b25d16a046d275beaec642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969895
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65486}
This reverts commit 53308bf7c0.
Reason for revert: Fails on multiple arm bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12441
Original change's description:
> [csa] use JSGraph to create constants in CodeAssembler
>
> Now that CodeAssembler uses optimizing TurboFan passes, creating
> constants without using the caching implemented in JSGraph leads to
> problems, since value numbering only works properly if all constants
> in the graph were introduced through the cache.
> To mitigate this, this CL creates the JSGraph earlier so that
> CodeAssembler can already use the same JSGraph used by later TurboFan
> optimizations.
> For other uses of RawMachineAssembler, everything stays as before.
>
> This issue is creating bot failures in
> https://chromium-review.googlesource.com/c/v8/v8/+/1958011
>
> Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65477}
TBR=tebbi@chromium.org,mslekova@chromium.org
Change-Id: I6df6782adfb40632f51681942efab9b591f72cab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969901
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65483}
MSVC wants the static cast, even if the constant fits in the narrower
type anyway.
R=ahaas@chromium.org
Change-Id: I40043c02db1524ac591f6dcea14333695a53d028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924356
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65482}
For out-of-line code, we need to generate the debug side table
information at the point where the out-of-line code is being triggered,
not when it is emitted (at the end of the function).
This CL also adds more tests to check the actual content of the debug
side table in different scenarios.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: I7714c86ee7edc4918b5ecc97cbded84c27b00e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967388
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65481}
This adds heuristics to perform young and full GCs on allocation
of external ArrayBuffer backing stores.
Young GCs are performed proactively based on the external backing
store bytes for the young generation. Full GCs are performed only
if the allocation fails. Subsequent CLs will add heuristics to
start incremental full GCs based on the external backing store bytes.
This will allow us to remove AdjustAmountOfExternalMemory for
ArrayBuffers.
Bug: v8:9701, chromium:1008938
Change-Id: I0e8688f582989518926c38260b5cf14e2ca93f84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803614
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65480}
