We do not need to go through the builtin when the function reference is
already set.
For faster checks, we ensure that
{WasmInstanceObject::wasm_internal_functions} is set at instance
object instantiation time. Therefore it does not need to be optional.
Change-Id: Ie0a6564c171c6a6e3424c3cc0eeae3c83929e616
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4005823
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84095}
We should invoke {LoadContextIntoSsa} just after the {IfException}
node after a call, rather than at the catch/cathcall point.
This way, we ensure that this is done before {BuildNestedLoopExits},
and we create a {LoopExitValue} node for the reloaded memory start/
size. Also, we only need to do so for Call and not Throw nodes.
Bug: chromium:1380646
Change-Id: Ibaa8fd7e39869c38c33cf62b1b6caf9238ced969
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008578
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84094}
This adds a separate test module and output expectation for names in
the custom "name" section in Wasm binaries.
Also fixes a small inconsistency: The index of both data and element
segments is now printed as a comment, in case one prints their name
(as we do for functions, globals, etc.)
Data segment names are currently not printed for consistency with
legacy behavior.
Change-Id: I8900f54b02e031a811dfd9be8326d6f63d26d4a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004717
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Auto-Submit: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84093}
The builtin inlining for FunctionPrototypeCall has to consider the case
where there is no new receiver to the call. It now does this by
considering the new call args to be kNullOrUndefined instead of kAny.
Drive-by cleanup of CallArguments to always consider the register count
and not the argument count, unifying the with/without receiver
correction for the list-of-regs and RegList cases.
Bug: v8:7700
Change-Id: I7e8cb7e9d654fdfcbb8add80e7a0a01a39d36504
Fixed: chromium:1381663, chromium:1381665
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008638
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84092}
The assumption in {DecodeAtomicOpcode} (added in
https://crrev.com/c/3990654) is only true for valid opcodes. Since
Atomic opcodes are variable-length encoded, it's possible to create
out-of-bounds atomic opcodes which violate the assumption.
This CL fixes that by checking for such out-of-bounds opcodes early in
the method. This replaces the assumption, which the compiler can now
derive from the if-statement.
R=ahaas@chromium.org
Bug: chromium:1381330
Change-Id: Ifaaceb0c8a765811fe2f934be1920bcb14675f36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84091}
The {BytecodeIterator} that also read locals declarations had a weird
fallback path to allow decoding of locals to fail, and just assume no
locals, decoding all bytes as code.
This CL removes that, and modifies the test that needs this
functionality to prepend a zero byte for encoding "0 locals".
R=jkummerow@chromium.org
Change-Id: I609e2bf6986eeb6380d65b03bf8512f0b09af764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4003078
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84088}
Previously, some float literals were printed with loss of information by
the Wasm disassembler, e.g., `1234567.5` was printed as `1234568`,
which is clearly wrong.
With this fix, the disassembler will always preserve information in its
output, i.e., it will print the correct `1234567.5`.
However, unfortunately, it will now print the binary representation of
`0.1` as `0.100000001`, since 0.1 can actually not be represented
exactly as a binary fraction.
Ideally, we would print the smallest representation of a float that,
when parsed again (e.g., by `wat2wasm`), produces the same float.
Unfortunately, there is currently no easy way to implement this.
There are several options, but they are either incorrect in other ways
or not available here:
- `DoubleToCString`: output will be even longer for decimal fractions
that cannot be represented in binary, since it will just round to the
nearest double instead.
- `printf` + `%g` format specifier: still prints `0.1` as `0.100000001`.
- `std::format`: C++20 only.
- `std::to_char`: C++17, but this particular header is not yet allowed.
- `absl::to_char`: Abseil is not available in V8.
It seems we have to choose either between losing information (such that
the output of the disassembler would not round-trip if assembled to a
binary again), or to have those ugly, long outputs.
Change-Id: Id40044a1724aeb115309688cbf05f71aa4745c6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004957
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84084}
In assertOptimized and assertUnoptimized, we can optionally pass in the
function name. We also used to pass in an optional 'sync' parameter, to
decide whether to wait for background compilations to finish before
checking state.
The sync parameter was removed in favour of explicit intrinsics, so fix
callers of assertOptimized to no longer try to set it. Also, use
function.name as the function name when no name was passed.
Change-Id: I8e98d4d02e2d097d059989ad78bf46b97b57bdca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000480
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84080}
With this change, ReduceJSCallMathMinMaxWithArrayLike will work on both PACKED_DOUBLE_ELEMENTS and HOLEY_DOUBLE_ELEMETNS kind.
It will also work when the opcode of arguments_list is JSCreateEmptyLiteralArray to deal with following use cases.
var array = [];
array.push(num1); // add elements
array.push(num2);
console.log(Math.min.apply(Math, array));
Change-Id: I39840a17607c31baea2c6b1d33218700f723d760
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4007927
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84079}
Restructure such that we only either shrink or grow the space, and only
at the end of the GC.
Bug: v8:12612
Change-Id: I7671e139b6023cd04f438f48401cf392d4549b8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980253
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84076}
It's been enabled by default since Chromium M95.
Also removes duplicate setup code for WebAssembly.Tag JS API
from WasmJs::InstallConditionalFeatures, since we're guaranteed
to set it up via the non-conditional WasmJs::Install.
Bug: v8:8091
Change-Id: Ic500feb655ad4fc0703ed226504847ca6d940537
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3996810
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84074}
This cl only convert the part for calendar in PR2395.
The part to cover TimeZone change will be coded in another cl.
Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal-isbuiltincalendar
Spec change https://github.com/tc39/proposal-temporal/pull/2395
PR2395 achieved consensus at the September 2022 TC39 meeting.
Also merge unnecessary const std::string& id version of IsBuiltinCalendar to the Handle<String> version and remove the unnecessary version.
Bug: v8:11544
Change-Id: Idb711d48dbcf929059b71c48681c03b30089adb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901200
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84073}
This CL adds "new.target" to the ScopeObject with the materialized
stack local variables. It's only available if the parser actually
allocates a variable for it, otherwise we currently throw a
ReferenceError.
The added test also ensures that "new.target" is only included for
debug-evaluate, but NOT for the scope view. Having ".new.target"
show up there would be more confusing than helpful.
Drive-by: Remove bogus DCHECK. The context we try to lookup
"new.target" can be anything, not just a `with` context.
R=bmeurer@chromium.org, leszeks@chromium.org
Bug: chromium:1246863
Change-Id: Id4f99b3336044904e3dc76912f65b6f63f092258
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4003039
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84069}
Objects in the shared heap do not have a usable Isolate (i.e. it cannot
execute code or have HandleScopes). PropertyIterator should be using the
currently executing Isolate via the Context instead.
Bug: chromium:1379616
Change-Id: I7ac87519ef4aa901ef7b71e00f98c2cba66e725b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3997702
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84052}
A failing memory bounds check is a debugging event. At debugging events
the value stack is observable and therefore has to match the speced
value stack. In Atomic.Wait the value stack got modified before the
bounds. With this CL memory bounds check gets moved to the beginning.
R=clemensb@chromium.org
Bug: chromium:1380498
Change-Id: I4a5fe4d49f05d5376cb717f3dc7ecca4fdcbd998
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998816
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84051}
Tests the disassembler output for all instructions and section types
from Wasm MVP (extensions such as reference types, SIMD, name section,
etc. will come in separate CL(s) and module(s), since they contain a
lot of additional instructions).
Also fixes a small issue in `MultiLineStringBuilder` found by ASAN.
The test checks the output of the disassembler against the text input
given to `wat2wasm` which generates the module given to the
disassembler.
The module in this test includes all non-extension instructions from
https://webassembly.github.io/spec/core/appendix/index-instructions.html
and module sections from
https://webassembly.github.io/spec/core/text/modules.html
at least once (and sometimes multiple times in case there are
variants).
Change-Id: Iaa8791cfc51431fb436f42b98604e83cd9258d06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4001769
Auto-Submit: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84050}
for-in enumeration creates an EnumCache, which is currently incorrectly
allocated in the per-thread heap. This CL preallocates the enum cache at
SharedStructType-creation time.
Also drive-by fixes typos in the enum cache code.
Bug: v8:12547, chromium:1379616
Change-Id: I1930f88844eca5ccfeebd8dfdcce4ad0bd80ee38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3997701
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84047}
This CL partially reverts https://crrev.com/c/2731527.
When we bootstrap a new context we need to force instantiate lazy
accessors so the debugger is able to set breakpoints on them.
Normally this happens automatically when we instantiate function
templates that have the "BreakAtEntry" bit set on them, but context
snapshots are just deserialized.
This means we need to do a heap walk and instantiate any lazy
accessor that we find and install the `DebugBreakTrampoline` should
the accessor require it.
Note that we keep the fix from the original CL: Instantiate
accessors only once and keep using that JSFunction.
R=bmeurer@chromium.org, leszeks@chromium.org
Bug: chromium:1368554
Change-Id: I4acde361ac021b082af62e895a7f43fd54de95f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4001520
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84041}
Change the test helper, %PrepareFunctionForOptimization, to permanently
mark functions for manual optimization (rather than being marked only up
to their next optimization). These functions will now never be heuristic
optimized, and will always require tier-up via intrinsics.
This prevents variants with low interrupt budgets from messing with
tests that are carefully controlling optimization state across
multiple optimisations, as well as simplifying the mechanism since we
no longer have to maintain the state machine of 'function state'.
Change-Id: I9a45312c70ba4a03b57924c3b3ee17e892ede5a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990787
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84038}
This CL introduces the mechanism for conservative stack scanning (CSS).
Behind a compile-time flag, it also introduces a CSS pass which scans
the stack during the GC marking phase and marking verification. This
pass is now redundant, i.e., it is not needed for the correctness of
garbage collection. It will be used for experimenting with CSS and for
benchmarking.
Bug: v8:13257
Change-Id: If35bc24fde3bc08c5735d9e2f1b67724f7e31ef7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968710
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84036}
V8 implements accessors defined in C++ via FunctionTemplates in a lazy
manner. When userland JS uses the accessor, V8 calls the corresponding
C++ code directly. Only when the user JS obtains a reference to the
function object itself (e.g. via Reflect.getOwnPropertyDescriptor) does
V8 instantiate a JSFunction object.
This makes breakpoint logic tricky. The debugger requires a JSFunction
when the user wants to set a breakpoint on such an accessor.
There is already some logic in place that forces instantiation of
accessors with a breakpoint on them.
Unfortunately that logic forgot to also install the
"DebugBreakTrampoline" on the instantiated JSFunction that will
actually pause execution. This CL fixes that.
Note that this is not the whole fix. Contexts deserialized from
snapshots need a heap walk that also forces instantation of the
accessors.
R=bmeurer@chromium.org
Bug: chromium:1368554
Change-Id: I346f614f380859b6419ae1df0ec6b0ca8234120a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000702
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84032}
In a few places, shared structs currently incorrectly assume all storage
is in-object. This CL fixes those and rename
CSA::StoreJSSharedStructInObjectField to CSA::StoreSharedObjectField to
reflect the genericity.
Bug: v8:12547
Change-Id: I7c155b6bc584fbdcdbd484fda38f9f8a1940953d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3997700
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84022}
The output of the disassembler is compared against a WebAssembly text
file that is also used to generate the module bytes given as input to
the disassembler.
This will be extended to cover all instructions/constructs of Wasm MVP
in the future. Also more tests are to be added, e.g., for the Wasm SIMD
and GC extensions.
Change-Id: I44648b295accfe91bbd0780170a2705f8a38b766
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3985913
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84018}
Copy the instanceof fast path from TurboFan, which emits an
'OrdinaryHasInstance' when there is no @@hasInstance symbol (which can
eventually become a constant true/false if we can look through the
prototype chain), and a direct call of @@hasInstance otherwise.
In particular, the call to @@hasInstance requires a continuation builtin
(to call ToBoolean), so add support for these too.
Bug: v8:7700
Change-Id: I14aee4346e98cd650f190b811cc7a733e33addae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990844
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84012}
Before this CL Oilpan young generation didn't support running with
stack. The problem was in initializing stores that don't have the write
barrier. If a GC happens during object initialization, the following
pointer stores can be missed:
struct GCed: GarbageCollected<GCed> {
GCed():
m1(MakeGarbageCollected<>()), // calls GC
m2(MakeGarbageCollected<>()) // old-to-young ref missing barrier
{}
...
};
The CL solves it by recording in-construction objects in a dedicated
remembered-set, which is retraced on next GCs.
Bug: chromium:1029379
Change-Id: I17975e2e2253b2792f71fb64a639e5bdb2ef4935
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990829
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84009}
Maps are now in old space, so start to report the first page in old
space now.
Bug: v8:12578
Change-Id: Icf08c9074558a2d47bb9f1f8df72cec9668d2b4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3986087
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84002}
Before https://crrev.com/c/3054114 we needed to pad the frame size to 4k
so that it fits into a 'sub' instruction as an immediate.
Since frame sizes larger than 4k use special OOL code now, this is not
required any more.
We thus remove the padding to save stack space.
R=ahaas@chromium.org
Bug: chromium:1379364
Change-Id: I155628141d2c0438415ccff36a4de8f7d1ad4fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3991050
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83999}
An Int32Constant might need to be tagged in Phi boundaries.
This exposes the Graph's smi constants to frames state
merger logic.
Bug: v8:7700, chromium:1378814, chromium:1379571
Change-Id: Ib373b44a76324eeb23cf9fef4483f70160cd54b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3993220
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83993}
... which is now an alias for V8_EXTERNAL_CODE_SPACE_BOOL.
Bug: v8:11880
Change-Id: I6fe3ee1ab7de7820671dc1543b233dbe18bd88d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990752
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83982}
This reverts commit e7f6d34cfe.
Reason for revert: Regressions and clusterfuzz bugs
Original change's description:
> [ic] Remove SameValue optimisation for constant fields
>
> We would previously try to preserve field constness if field assignment
> was assigning the same value. It's unexpected that real-life code would
> be assigning the same value multiple times to an intentionally constant
> field, so this was additional bookkeeping with unclear value.
>
> Replace this with not doing it, and considering any write to a constant
> field to convert it to mutable. In particular, this means that stores to
> existing constant fields in TurboFan become unconditional deopts, rather
> than emitting additional code to check whether the value is the same.
>
> Locally, this deopt doesn't fire on our peak-performance benchmarks.
>
> Bug: v8:5495
> Change-Id: I12216c5f10a00f42be32c64ca3afe7cf59b4e7f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976516
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83955}
Bug: v8:5495
Change-Id: Ifeeceb773af04e9dd5e069821cd128a1cdbedcf5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990683
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#83970}
Tests flagged as 'raw' need to run without the harness. The language/module-code/eval-gtbndng-indirect-faux-assertion test was failing only because it was running with the harness.
Bug: v8:10958
Change-Id: If00f3ec8abc697d9b3727691e12ae0da7ce8c785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3984052
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83964}
V8's C++ API does not give a way to tell whether an ArrayBuffer has
been detached from the `v8::ArrayBuffer` class. In fact, as far as can
be told from the C++ API without running JS code, detached
ArrayBuffers behave the same as zero-sized ArrayBuffers and there is
no way to observe the difference. However, this difference can be
observed in JS because constructing a TypedArray from a detached
ArrayBuffer will throw.
This change adds a `WasDetached` method to the `v8::ArrayBuffer` class
to give embedders access to this information without having to run JS
code.
Bug: v8:13159
Change-Id: I2bb1e380cee1cecd31f6d48ec3d9f28c03a8a673
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810345
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83963}
Since crrev.com/c/3973310 which renamed the isolate scopes, the unit and
cctests for the object-start bitmap and the conservative stack visitor
have broken.
Bug: v8:13257
Change-Id: If8a498827f2085108cf0740a9c5c994145424fc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980255
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83960}
This reverts commit 57db447bf2.
This reland adds handling for Oddballs in Int64Add and Int64Sub in the
SLVerifier and updates the Verifier to check that Int32Constant and
Int64Constant are correctly typed with Type::Machine().
Original change's description:
> [turbofan] Optimize rab/gsab-backed TypedArrays and DataViews
>
> This CL adds TurboFan optimizations for length and element access
> of TypedArrays and DataViews that are rab/gsab-backed.
>
> To enable this optimization, this CL builds the necessary machinery
> required to allow machine operators at the front of the pipeline
> (before simplified lowering). Some key changes to allow this are:
> - Introduce Type::Machine() to allow the typer and the verifier to
> provide a type to those machine operators in parts of the pipeline
> that require nodes to be typed.
> - Add EnterMachineGraph and ExitMachineGraph operators that define
> the boundary between early machine graphs and the normal graph with
> JS semantics.
> - Give Branch operators a BranchSemantics parameter to distinguish
> between machine branches (condition is a machine level value) and
> JS branches (condition is a JS boolean value) and have phases that
> handle branches decide on the branch's semantics based on this
> parameter instead of the position in the pipeline.
> - Extend SimplifiedLowering and SimplifiedLoweringVerifier to handle
> machine graphs. In particular, constants required special handling,
> because they are cached in the graph but they may have uses in both
> a machine and the JS graph, which prevents consistent typing of
> them.
> - Moved lots of logic from JSCallReducerAssembler into
> [JS]GraphAssembler such that functionality can be shared between
> different phases (e.g. JSNativeContextSpecialization and
> JSCallReducer need to generate logic to compute a TypedArray's
> byte length). Extended assembler interface in general with
> additional TNode<> overloads.
>
>
> Bug: v8:11111, chromium:1358505
> Change-Id: Ife006b8c38a83045cd3b8558acbfdcb66408891f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3898690
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83881}
Bug: v8:11111, chromium:1358505, v8:13412, chromium:1378439, chromium:1378162
Change-Id: I89702c4be05e0e71cd6836dc50d2e26736a55429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980759
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83956}
We would previously try to preserve field constness if field assignment
was assigning the same value. It's unexpected that real-life code would
be assigning the same value multiple times to an intentionally constant
field, so this was additional bookkeeping with unclear value.
Replace this with not doing it, and considering any write to a constant
field to convert it to mutable. In particular, this means that stores to
existing constant fields in TurboFan become unconditional deopts, rather
than emitting additional code to check whether the value is the same.
Locally, this deopt doesn't fire on our peak-performance benchmarks.
Bug: v8:5495
Change-Id: I12216c5f10a00f42be32c64ca3afe7cf59b4e7f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976516
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83955}
This is a follow-up to commit d1a11dd15a.
This reverts commit 9182c028c1.
Change-Id: I4555f329314955e6a4a40dd40e22dc12a570c89e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3986086
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83952}
