Debugging does not work reliably with multiple isolates involved. Thus
skip all tests that we saw flaking so far.
R=thibaudm@chromium.org
Bug: v8:10359, v8:10358
Change-Id: I119f8fdb19efb91f7d9fad0f510ffb68c646e784
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126906
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66906}
The last test will not be fixed in the context of enabling debugging in
Liftoff. Instead, it will fail until we implement anyref in Liftoff.
Thus, assign the new tracking bug to it.
R=thibaudm@chromium.org
Bug: v8:10351, v8:10356
Change-Id: Ic184f390841b0994bf37bbf5f7ecc13e6cf1f957
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124322
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66905}
When stepping in from JS, the stepping frame ID will not be set.
Instead of ensuring to set it properly, we can just skip the check for
the frame ID. It was needed before, when we didn't properly reset
stepping information. Now, it's redundant anyway.
Also, ensure that we don't redirect to the interpreter if the
--debug-in-liftoff flag is set.
Drive-by: Fix and clang-format some parts of the test (no semantic
change).
R=thibaudm@chromium.org, szuend@chromium.org
Bug: v8:10351
Change-Id: I58a3cd68937006c2d6b755a4465e793abcf8a20c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124317
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66904}
Rework the remaining tests in grow-memory to check for first 5 offsets
and last 5 offsets in the relevant pages.
Bug: v8:7783
Change-Id: I59435f3c1a6f50ff808fdd045a6c7039860fc72e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116647
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66896}
LoadTransform is not implemented on BE machines and instead,
it is divided into 2 separate "Load" and "operation" nodes.
We need to assure same behaviour applies on S390 simulator, however,
S390 Sim does not execute BE code, it assume generated code is in
LE format hence "V8_TARGET_BIG_ENDIAN" is set to false when running
on Sim.
This CL includes V8_TARGET_ARCH_S390_LE_SIM to assure same
behaviour occurs when running on the Sim until V8_TARGET_BIG_ENDIAN
can also include the simulator.
Change-Id: If1decf9eccb43ac721b57d58362b8934d49cbff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124847
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66895}
The output extends by four more breaks, since when stepping out of the
function that has the breakpoint, we now also step through the two
other functions on the stack.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I4b042cad0d88b923c3894fe979c43837260eb958
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124315
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66892}
There are only three tests with differing behaviour if Liftoff is used
for debugging.
This CL thus stages the --debug-in-liftoff flag behind --future (tested
by the "future" variant) and excludes the three tests.
This allows us to test the other (already working) tests for
regressions, and iteratively shrinking down the list of failing tests.
Drive-by: Tier down modules in tests before testing debugging features
to avoid hitting a DCHECK in Liftoff recompilation for debugging.
R=thibaudm@chromium.org, ecmziegler@chromium.org
Bug: v8:10351
Change-Id: I3b1dd1a29258ecf13c1f60020fb06358005558d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122021
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66889}
This CL adds basic infrastructure for:
- MakeGarbageCollected
- GarbageCollected and related type traits
- Heap (API / internal)
- Basic allocation based on malloc
- CollectGarbage without marking
This allows for allocation and reclamation through an explicit GC
call. No objects are held alive from any source (stack, globals,
refs), yet.
The exact wiring of platform is future work.
Change-Id: I81b7c0ba7b525188f8c0bf9de3b7af35d34322af
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120538
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66887}
This patch changes the order in which stack values are shown
in the stack scope. As a result, changes to the stack show up
at the end of the stack.
Bug: chromium:1043034
Change-Id: I735fc29d3957b6484589554ce046114e1b7bd9e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122987
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66884}
This is a minor cosmetic fix. Wasm opcodes are bytes, hence they should
always be printed as an even number of hexadecimal digits.
Note that currently we only print a single byte anyway, but in the
future we will want to extend this to correctly parse multi-byte
opcodes. Those will also be printed as an even number of characters
then.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I2423277b470d74c1c72cb619c2a43bb978423bc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122025
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66883}
The asm-wasm-f32 and asm-wasm-f64 tests run through a bunch of different
constants. For the binops, they run through a cross product of the
inputs. This patch trims down the number of constants used.
The selection of constants to remove is quite arbitrary - the intial
patch introduced a lot of magic constants that look random or has some
pattern. I don't think they mean anything special, especially for f64
form since those values all fit in a f64. For f32 we still have a bunch
of values to exceed the maximum integer representable in f32.
Bug: v8:7783
Change-Id: If34b084a11acdf21b1d2933fdd0cab65be1738c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116988
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66882}
Yet another corner case how non-deterministic timestamps slipped into
the tests.
Bug: chromium:1064900
Change-Id: I33e8b4c8141b3854b7eca5d7ad9b45b6f5130d9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120584
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66881}
Rework testMemoryGrowPreservesDataMemOp tests so that they only test the
first and last 5 offsets within the page, instead of every offset.
Slight logic change: instead of storing the value C - offset (where C is
a constant that is different for 32 and 16 memops), we store just the
value offset. This allows us to combine the logic for all 3 memops (32,
16, and 8). But we need to add a modulo so that in the 8 bit case, we
don't store a value that exceeds the maximum (the other cases will never
hit a case that exceeds the max).
Bug: v8:7783
Change-Id: Ibfdc77555ba2ca26391eba303050a03538f6012d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117633
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66879}
We were missing test cases for i16, i64, and f64. It's not super
critical, but it's also an easy addition, and helps bring coverage of
memory-tracing.cc up (close to 100% now).
Change-Id: Ib8433f8615c900d8665ccbc33e12d6fd05d51336
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2121168
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66878}
Most control structures in WebAssembly do not have a clear execution
semantics, they are more like markers. Hence the execute state, and the
change in the state, when breaking on them and stepping over them is
unclear.
Hence this CL just makes them non-breakable. If the user tries to set a
breakpoint on them, this breakpoint will automatically be propagated to
the first instruction after the respective control opcode (this is
tested for other cases in existing tests).
R=thibaudm@chromium.org
Bug: v8:10326
Change-Id: Iaf540a94789c9cbc87d23ddfb794e4b01776b49f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122017
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66876}
We were sometimes stopping on a one-shot breakpoints in JS code even
though the last user action was actually a resume.
This CL fixes that clearing all stepping in JS whenever we hit a
breakpoint in wasm.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: Ie5d12bb0c9e766bcbd5ad0aa225a8b14b4d608b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120588
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66869}
This change adds a stack scope for wasm debugging.
Currently the local scope contains both local variables as well as
the expression stack. For now, this change duplicates the information
available on stacks into the stack scope, until we have added
support for the stack scope in the DevTools front-end.
Bug: chromium:1043034
Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66867}
std::atomic loads are marked as nodiscard on MSVC. Fix the warning by
feeding the load into the USE() macro.
Bug: chromium:1056170
Change-Id: I72ca42d42d268c4b961d96618250229a53709472
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120543
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66866}
For a bunch of s8x16, s16x2 and s32x4 shuffle ops (generated by
s8x16shuffle).
Bug: v8:9561
Change-Id: I0e5cd8a90edba8bc15918c0ca1dc830475db2769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110952
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66865}
Using the "logSourceLocation" function from protocol-test.js prints
slightly better location information for wasm, and especially much
better information for JS breakpoints. This helps understanding and
debugging these tests.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I51c7d168d2cb19fb8469b4a2eb372c2b95650fcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120539
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66863}
This reverts commit 0c72c71900.
Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer
Original change's description:
> Move branch inversion on ==0 into platform-agnostic reducer
>
> This change is based on a discussion from
> https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
> wherein Tobias suggested moving the folding away of ==0 operations out
> of the platform-specific instruction selectors and into the
> MachineOperatorReducer. I noticed that CommonOperatorReducer already
> handles some very similar cases, so I have tried putting the ==0 folding
> into CommonOperatorReducer instead. I'm happy to move it into
> MachineOperatorReducer if that's better; I still don't have a very good
> understanding of how roles are separated among reducers.
>
> Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66688}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1061767
Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66862}
This adds HeapObjectHeader, a meta object that is put in front of
every managed object. HeapObjectHeader provides accessors for:
1. GCInfoIndex
2. In construction bit
3. size
4. Mark bit
Meta info is distributed among two uint16_t fields as (1.,2.) and
(3.,4.). This is convenient as the non-bit accessors (size,
GCInfoIndex) are constant during marking.
Object layout see heap-object-header.h.
Note: The current implementation does not bypass ASAN poisoning and
assumes an unpoisoned header whenever performing an access.
Bug: chromium:1056170
Change-Id: I753f15467ed5c2b22b47e64d3aa5a3c1baddf8e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116031
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66861}
This enables the --debug-in-liftoff flag in the wasm-scope-info test.
The expected output slightly differs, because we get another breakpoint
at the end of the function body, which was actually missing before.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: Ic2628b26591763cea17403f74fe0f6d935633e6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120535
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66859}
A StringView is pretty light, so this should be similar to
how absl::string_view is typically used, e.g. see the guidance here:
https://github.com/abseil/abseil-cpp/blob/master/absl/strings/string_view.h
I suspect this reasoning holds even though StringView (defined
just above StringBuffer in v8-inspector.h) carries an additional bool.
This yields a small simplification of the StringBuffer implementations.
Change-Id: I03f850049afe2327913070838f39649fcdfa6fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045110
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66858}
MSVC 19.25 complains about signbit being ambiguous between
signbit(float) and signbit(double) overloads when called with an int8_t.
To remove the ambiguity, cast to a double.
Change-Id: I698f05eed9248eef493bbe46b75fcd07e37e2a05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66856}
For some input types containing -0 but not +0, the result type of
NumberMin and NumberMax would unnecessarily include +0. However, for
some larger inputs, the result type would not include the spurious +0,
thus breaking monotonicity.
The CL fixes this and addresses a TODO as well.
Bug: chromium:1063661
Change-Id: Icd56d6102fbea12a2d96aa063a803b1052c714b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116199
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66854}
Add LocalHandleScope to allow for local handles in LocalHeaps
(background threads). This class is similar to HandleScope which still
needs to be used on the main thread. When performing a GC, the main
thread halts all background threads at a safepoint such that it can
safely iterate their roots.
Bug: v8:10315
Change-Id: Id8f5d54cc2535e004081ccdef15dc03a39b2d0f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111218
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66853}
A StepOver at a return (either explicit return instruction, or implicit
return at the end of the function) should stop again in the caller
frame.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I313e6b612ac52e73b33ef07c6da1ced2aa0db600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110250
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66852}
This fixes issues with replacing the return address of deeper (non-top)
wasm frames, i.e. frames which are at a call position. The replaced
address should also point after the call in the new code, so we don't
execute the same call again.
This is achieved by using slightly different encodings for breakpoint
positions and other (wasm instruction) positions. Breakpoints set
{is_instruction} to {false} in the source position table entry, whereas
usual wasm instruction set it to {true}.
Also, during stack walking for OSR, we remember whether we want to OSR
to the position before the instruction (if it's the top frame), or after
the call instruction (if it's deeper in the stack). We then use the
{is_instruction} predicate to find the right location.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66850}
Rework the testMemoryGrowReadWrite and testMemoryGrowZeroInitialSize
tests. Combine the different sized tests (32, 16, 8 bit integers) into a
single base tests, taking in function arguments to specify which
load/store function to call from the module exports.
Also reduced the number of checks made in each test. Previously the test
was asserting on every single valid offset. Now it checks the first 5
and the last 5 of each page of memory. From a quick local test using
`time`, it speeds up this test on x64 from ~40s to ~20s.
There is more work to be done: there are other tests below that also
assert on each offset, we can change those in a future patch.
The goal is to be able to run this on arm simulators
sufficiently quickly, and not require to mark this test as slow.
Bug: v8:7783
Change-Id: I2b17cf1811de6c26332d7e8f91efbbac3e89f6e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116601
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66848}
GCInfo and its related infrastructure is used to record information
about types. Currently, we store finalization and vtable information.
Future changes will introduce naming and tracing, similar to Oilpan in
Blink.
Information is stored in a process-wide global table that is
maintained at runtime. For static builds such information can be
recorded in the binary without the runtime overhead which is future
work.
This ports `third_party/blink/renderer/platform/heap/gc_info.{h,cc}`
on a semantic level. In addition to adjusting to V8's needs, we also
re-commit the already filled parts of the info table as read-only when
possible, making it harder to override type information.
Bug: chromium:1056170
Change-Id: Ib01eb24e6f8a94a4a647efde7af37689f8c20ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111214
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66847}
This might help reduce flaky test results caused by too high memory
consumption due to the large Float32Array in regress-crbug-1057653.js.
Bug: v8:10333
Change-Id: Id99ebb67ebe5a7a730e44cd8967ebbea905ccdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108547
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66836}
"By my deeds I honor him. V8."
- Add basic build files for library and unittests.
- Integrate unittests also in existing V8 unittests for simplicity.
The CL also adds FinalizerTrait and unittests to allow building a
testing target that executes code.
FinalizerTrait is used to determine how managed C++ types are
finalized. The trait should not be overridable by users but needs to
be exposed on API-level to avoid including library-internal headers.
Bug: chromium:1056170
Change-Id: I64d91053410a17a7835e50547f58990625d2da28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108549
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66834}
The behaviour was clarified in the spec:
https://github.com/WebAssembly/exception-handling/pull/97
br_on_exn (and also rethrow, which will be added in another CL) should
trap on nullptr. This CL implements this by an explicit check on each
br_on_exn (within {GetExceptionTag}). This check will be redundant if
several br_on_exn follow each other. Since also the runtime call for
{GetExceptionTag} is redundant, and also the fact that we do a runtime
call is suboptimal, I consider the whole implementation prototypical for
now anyway.
R=jkummerow@chromium.orgCC=aheejin@chromium.org
Bug: v8:10128
Change-Id: I234c3183f93fe0884aadd2ab6dbd6c2b7a07c660
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113381
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66826}
Introduces a new macro BUILD_V (v is for vector) that pushes bytes into
a vector (instead of directly in an array initializer, see BUILD). This
has the positive effect of being able to handle opcodes of multiple
bytes (e.g. SIMD opcodes bigger that 0xfd80). Because of this "API"
change, our helper macros in test-run-wasm-simd.cc and wasm-run-utils.h
need to change too. So, we introduce new macros (suffixed by _V), that
will call the appropriate lambdas defined in BUILD_V, that knows how to
push bytes into the vector, and also can handle multi-byte opcodes.
This design has a bit of duplication and ugliness, but was chosen to
reduce the impact of existing tests. No restructuring of test code is
required, we only need to add suffix _V.
Note that we do not have multi-byte opcodes yet (in wasm-opcodes.h),
this change will be breaking, and requires all the tests to be updated
to use _V macros first.
Bug: v8:10258
Change-Id: I86638a548fe2f9714c1cfb3bd691fb7b49bfd652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107650
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66812}
Now that it is implicit in function entry and loop iteration, there is
no need for an explicit bytecode.
Also updated tests that used explicit bytecodes.
Bug: v8:10149, v8:9960
Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66811}
Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.
Adding tests that test this advancing for wide and extra wide JumpLoops.
Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.
Bug: v8:10149, v8:9960
Fixes: v8:10149
Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66809}
I'm unable to produce an issue with this test locally, so let's
try to enable it again.
Big: v8:6587
Change-Id: Ida834ac4ccf8c25d8f5c1e09fc57479db46a1873
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108722
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66803}
This is a reland of e80ca24c80
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66798}
Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on interpreter and
arm64.
These operations are behind wasm_simd_post_mvp flag, as we are only
prototyping to evaluate performance. The codegen is based on guidance at
https://github.com/WebAssembly/simd/pull/201.
Bug: v8:10308
Change-Id: I835aa8a23e677a00ee7897c1c31a028850e238a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099451
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66793}
Update the "hook on function call" flag also in the wasm case, and
slightly change the {IsStepping} logic to stop in any frame if the last
step action was anything other than StepNext.
In future CLs, this has to be extended further for StepOut and for
StepOver at a return location.
When that is done, we can also reenable more stepping in the test.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66789}
This implements the first part of WebAssembly debug evaluate. The patch
includes the foundation required to execute evaluator modules. It only
implements the first of the APIs of the evaluator module spec.
Bug: chromium:1020120
Change-Id: I06ec98a63d0a0ec8d81c2eac4319c4b85d3e16c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089936
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66787}
This reverts commit e80ca24c80.
Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
TBR=jgruber@chromium.org,iireland@mozilla.com
Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10303
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66786}
This patch modifies irregexp's error handling. Instead of representing
errors as C strings, they are represented as an enumeration value
(RegExpError), and only converted to strings when throwing the error
object in regexp.cc. This makes it significantly easier to integrate
into SpiderMonkey. A few notes:
1. Depending on whether the stack overflows during parsing or
analysis, the stack overflow message can vary ("Stack overflow" or
"Maximum call stack size exceeded"). I kept that behaviour in this
patch, under the assumption that stack overflow messages are
(sadly) the sorts of things that real world code ends up depending
on.
2. Depending on the point in code where the error was identified,
invalid unicode escapes could be reported as "Invalid Unicode
escape", "Invalid unicode escape", or "Invalid Unicode escape
sequence". I fervently hope that nobody depends on the specific
wording of a syntax error, so I standardized on the first one. (It
was both the most common, and the most consistent with other
"Invalid X escape" messages.)
3. In addition to changing the representation, this patch also adds an
error_pos field to RegExpParser and RegExpCompileData, which stores
the position at which an error occurred. This is used by
SpiderMonkey to provide more helpful messages about where a syntax
error occurred in large regular expressions.
4. This model is closer to V8's existing MessageTemplate
infrastructure. I considered trying to integrate it more closely
with MessageTemplate, but since one of our stated goals for this
project was to make it easier to use irregexp outside of V8, I
decided to hold off.
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66784}
This reverts commit d91679bf3a.
Reason for revert: Seems to cause UBSan errors
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66783}
UnoptimizedCompileFlags defines the input flags shared between parse and
compile (currently parse-only). It is set initially with some values, and
is immutable after being passed to ParseInfo (ParseInfo still has getters
for the fields, but no setters).
Since a few of the existing flags were output flags, ParseInfo now has a
new output_flags field, which will eventually migrate to a ParseOutputs
structure.
Bug: v8:10314
Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66782}
"I64x2Eq", "S1x2AnyTrue" and "S1x2AllTrue" do not yet have lowering
implemented hence some of the test case may fail on s390x
hardware without AVX support.
Change-Id: Ice01bcaed78950fbad36e2ba37c8f7ae5d10b59b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107763
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66780}
We don't ever want a node's type to become less precise.
Also move a part of JSTypedLowering::ReduceJSStrictEqual that
can be expressed solely in terms of types into the typer, where
it generalizes an existing case.
Change-Id: I37c58fed48f606f6fe34e98e5f066434e50cb6c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106204
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66763}
To ensure good error messages, we do create bindings even for non-const
fields but then add a new error message mechanism when accessing such
a binding.
Bug: v8:7793
Change-Id: I2f20483514660c5ce92202d301c631f6ac055446
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096617
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66762}
In the runtime, we always had a convention to use int-typed accessors
for Smi fields. For Torque-generated classes, we kept them Smi-typed
but then added int wrappers around that.
This CL makes Torque generate int-typed accessors directly, removing the
need for these wrappers.
TBR=hpayer@chromium.org
Bug: v8:7793
Change-Id: I348e1d96295c9676fafda32b7d49088848527f89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66760}
- Allow type expression for abstract type supertypes.
For consistency, and ease of implementation, also allow this for enums.
- Allow subtyping of structs. This requires changing all places where we
checked for struct types and instead check if we have a subtype of a
struct type.
- This allows defining two subtypes of the Reference<T> struct for
mutable and constant references. Mutable references are a subtype of
constant references.
- &T desugars to MutableReference<T>
const &T desugars to ConstReference<T>
- A const field of a class produces a constant reference.
A const field of a mutable reference to a struct is const.
A mutable field of a const reference to a struct is const.
- It is possible to assign a new struct value to a mutable reference to
a struct, even if the struct contains const fields. This is analogous
to allowing assignments of let-bound structs with constant fields.
Not in this CL:
- A notion of const slices.
- Applying const to appropriate class fields.
Bug: v8:7793
Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66759}
This Cl enables simd on machines which support
VECTOR_ENHANCE_FACILITY_1. It also enables related tests to
match execution on x64.
LoadTransform tests must be skipped on the simulator until a future CL
matches behaviour between native BE and its simulator on LE.
Change-Id: Iaadc32e0388bf15d3d7c550062a373fb403b65c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107053
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66754}
And fix a few issues revealed by this new test. Incidentally, the test
uses removeBreakpoint which was still untested with Liftoff. But as
expected this seems to work out of the box.
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: Ifa4e867737d925ea8c6c9731575a32f3da3e16dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106206
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66752}
Generate a BTI instruction at each target of an indirect branch
(BR/BLR). An indirect branch that doesn't jump to a BTI instruction
will generate an exception on a BTI-enabled core. On cores that do
not support the BTI extension, the BTI instruction is a NOP.
Targets of indirect branch instructions include, among other things,
function entrypoints, exception handlers and jump tables. Lazy deopt
exits can potentially be reached through an indirect branch when an
exception is thrown, so they also get an additional BTI instruction.
Bug: v8:10026
Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66751}
Add a scriptLanguage enum to the new scripts events. This overhauls
crrev.com/c/2011083 that was related. Report the code section offset
as well as the script language on the Debugger.scriptParsed and
Debugger.scriptFailedToParse events.
Bug: chromium:1057569
Change-Id: I40b43f28f0b3e094720db4fc1f07db1a0c293ee0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083025
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66749}
Track list of all local heaps in the Safepoint class instead of the
Heap.
Bug: v8:10315
Change-Id: I1a1c847502ab5e8f368d4cc12d3cbaf3672af7cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106197
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66745}
This is a reland of 2c834c5364,
in which node replacement was too aggressive.
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
Change-Id: I5d306092dde4119629af4c5e7e424a0e9a14310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106193
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66742}
This adjusts v8::[Shared]ArrayBuffer::NewBackingStore to allow passing
a known empty deleter -- v8::BackingStore::EmptyDeleter. Such API is
useful if the backing store memory is static or is manually managed.
We can skip adjusting the amount of external memory for ArrayBuffers
with empty deleters and thus avoid scheduling ineffective GCs.
Bug: chromium:1061960
Change-Id: I0ef5b2b0839098beb59d5cebbb28f9f81a73a042
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105355
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66740}
At the moment when the static private method is unused
in source code (either explicitly or through eval) but is accessed
at runtime through the debugger, and there are no other potential
references to the class variable in the source code otherwise,
the reference to the class variable is lost here since the class
variable would not be context-allocated, then we could not rebuild
a proper brand check for it.
For now, a ReferenceError would be thrown and the method is considered
"optimized away", similar to how unused ordinary methods in closures
work. Before this patch it would DCHECK when generating bytecode
for the debugger instead of throwing errors.
Bug: v8:9839, v8:8330
Change-Id: I5d63131a7bdba141d01a3e6459bc27d0f5953c1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095637
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66734}
Add safepoint mechanism to stop concurrent threads and bring them to a
safepoint. Threads are stopped before the safepoint and after e.g. the
GC resumed again. Each thread needs to be stopped in a safepoint, such
that all roots can be iterated safely.
Running threads need to be cooperative and are required to perform
regular safepoint polls.
The last version of this CL was reverted because safepoint_requested_
wasn't initialized (see https://crrev.com/c/2105634).
Bug: v8:10315
Change-Id: I6ef244c0fb31c178589b5e3d1c62687a8dd65768
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105635
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66732}
This reverts commit c84963eaa7.
Reason for revert: Fails on msan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/31376
Original change's description:
> [heap] Introduce safepoint mechanism
>
> Add safepoint mechanism to stop concurrent threads and bring them to a
> safepoint. Threads are stopped before the safepoint and after e.g. the
> GC resumed again. Each thread needs to be stopped in a safepoint, such
> that all roots can be iterated safely.
>
> Running threads need to be cooperative and are required to perform
> regular safepoint polls.
>
> Bug: v8:10315
> Change-Id: I47f07e7d2ef5bc5adbba6b9e8e79a1f0f45b97ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102578
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66727}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: If11281b2b9fc622b91261417b202676f23f60b50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105634
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66729}
Add safepoint mechanism to stop concurrent threads and bring them to a
safepoint. Threads are stopped before the safepoint and after e.g. the
GC resumed again. Each thread needs to be stopped in a safepoint, such
that all roots can be iterated safely.
Running threads need to be cooperative and are required to perform
regular safepoint polls.
Bug: v8:10315
Change-Id: I47f07e7d2ef5bc5adbba6b9e8e79a1f0f45b97ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102578
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66727}
Port 83ff405b1a
Original Commit Message:
Flood functions with breakpoints to prepare them for stepping. With a
small modification to the runtime function, this already implements a
basic step over functionality.
We still cannot resume, step in or step out (including stepping over a
return instruction).
R=thibaudm@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Id153b2611c528e679e8d7722e3d209fb15bcf6d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105055
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66724}
Fix the test-interpreter and test-interpreter-instrinsics by adding the receiver
as an argument instead of relying on an undefined receiver.
Change-Id: I7af3216b915581155bc320b27a5454c78d04f1f5
Bug: v8:10325
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102568
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66723}
This tests inspecting a bigger number of registers (covers all registers
on many platforms). It also executes all four intrinsic types (i32, i64,
f32, f64).
R=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I340696d525e4001f241bb22f62f0338018ad9804
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102575
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66720}
This implements inspection of live registers on breakpoints in Liftoff.
To that end, the frame pointer of the WasmDebugBreak frame is remembered
when iterating the stack. Based on a platform-specific implementation of
{WasmDebugBreakFrameConstants}, the offset of the respective register
within that frame is computed, and the value is read from the frame.
As a drive-by, the wasm debug side table is storing register codes as
liftoff codes, which can also store register pairs (needed for i64 on
32-bit platforms, and for SIMD, which is not supported yet).
R=jkummerow@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66719}
This reverts commit 2c834c5364.
Reason for revert: several clusterfuzz issues, e.g. 1061805
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
TBR=neis@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I6e5b655bb465087a50ebaa2088795c6f920c2e51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2104892
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66717}
to properly choose named or indexed mode
Bug: chromium:1059738
Change-Id: Icd086fee31079f52770742afa54fc946acb1fd81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101005
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66702}
Flood functions with breakpoints to prepare them for stepping. With a
small modification to the runtime function, this already implements a
basic step over functionality.
We still cannot resume, step in or step out (including stepping over a
return instruction).
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: Ia4a6335d24c1a511c2f1fc9b48d728f327b3df56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098732
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66697}
s128.store should be in the list for generating kStmt, not kWasmS128.
No regression test added because the generated JS file is not helpful
for this bug - the failed assertion is in the fuzzer, not the engine.
Bug: chromium:1061049
Change-Id: I44092fa10c57aeeb34f1c6c5a7d655def31a7363
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101927
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66692}
This change is based on a discussion from
https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
wherein Tobias suggested moving the folding away of ==0 operations out
of the platform-specific instruction selectors and into the
MachineOperatorReducer. I noticed that CommonOperatorReducer already
handles some very similar cases, so I have tried putting the ==0 folding
into CommonOperatorReducer instead. I'm happy to move it into
MachineOperatorReducer if that's better; I still don't have a very good
understanding of how roles are separated among reducers.
Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66688}
In preparation for adding reference types, which need an additional
parameter to indicate the referenced type.
Bug: v8:7748
Change-Id: If4023f3d9c7f42ed603b69c43356d2e8b81a0daa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091471
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66687}
x64's cmpxchgl instruction does not zero-extend the register. The stale
high word caused the difference in the results of the interpreter and
Liftoff/TurboFan.
R=clemensb@chromium.orgCC=zhin@chromium.org
Bug: chromium:1059529
Change-Id: I0fd440bee26e25b90b29533cfa9151e4d87754e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098726
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66685}
... such that we have only a single representation for special
constants such as undefined, namely the corresponding bitset.
With this CL the following property holds:
t1.IsSingleton() /\ t2.Is(t1) => t1.Is(t2)
Also clean up the Type interface and improve test coverage a little.
Change-Id: I074e20047c92e2c8215c2d438f2627f4ffdbc409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096631
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66684}
This CL is a step towards making StackChecks implicit. In a follow-up CL
said StackChecks will become implicit within JumpLoops.
Cq-Include-Trybots: luci.chromium.try:linux-rel
Bug: v8:10149, v8:9960
Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66668}
Instead of directly using the Heap class concurrent threads will use the
LocalHeap class for all heap operations.
Bug: v8:10315
Change-Id: Ie007abb5b914af7f2507c9e790f34baacbcdf588
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096620
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66663}
Report the allocated size of global handles in GetHeapStatistics as
well, not including free handles.
Bug: chromium:1060192
Change-Id: I1aedba36735f897cd8518edbb5ef2261cc348bff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093493
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66651}
Port b766299d2c
Port 9592b043ee
Port d915b8d668
Original Commit Message:
Code object iteration was missing logic for RELATIVE_CODE_TARGET
reloc entries. Garbage collection could thus miss objects that were
referenced only as targets of pc-relative calls or jumps.
RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
at mksnapshot-time.
This exposed another issue in that the interpreter entry trampoline
copy we generate for profiling *did* contain relative calls in
runtime-accessible code. This is a problem, since code space on arm is,
by default, too large to be fully addressable through pc-relative
calls. This CL thus also disables the related
FLAG_interpreted_frames_native_stack feature on arm.
objects.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66644}
Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a
case-folding algorithm that doesn't quite match the Unicode
definition. There are two places in irregexp that need to do
case-folding. Prior to this patch, neither of them quite matched the
spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch).
This patch implements the "Canonicalize" algorithm in
src/regexp/special-case.h, and uses it in the relevant places. It
replaces special-case logic around upper-casing / ASCII characters
with the following approach:
1. For most characters, calling UnicodeSet::closeOver on a set
containing that character will produce the correct set of
case-insensitive matches.
2. For a small handful of characters (like the sharp S that prompted
this change), UnicodeSet::closeOver will include some characters
that should be omitted. For example, although closeOver('ß') =
"ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß'
canonicalizes to itself, and should not match 'ẞ'. In these cases,
we can skip the closeOver entirely, because it will never add an
equivalent character. These characters are in the IgnoreSet.
3. For an even smaller handful of characters, UnicodeSet::closeOver
will produce some characters that should be omitted, but also some
characters that should be included. For example, closeOver('k') =
"kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN
SIGN should not match either of the other two (step 3.g). To handle
this, we put such characters in the SpecialAddSet. In these cases,
we closeOver the original character, but filter out the results
that do not have the same canonical value.
The computation of IgnoreSet and SpecialAddSet happens at build time,
using the pre-existing gen-regexp-special-case.cc step.
R=jgruber@chromium.org
Bug: v8:10248
Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66641}
In https://crrev.com/c/2084321 I added s128 load store to the fuzzer,
and updated the memop generator to use IsPrefixOpcode check. But it was
used wrongly. IsPrefixOpcode checks a 1 byte opcode and see if it is a
prefix opcode, but if memory_op is already a 2 byte opcode, it will fail
the IsPrefixOpcode check.
Bug: chromium:1059899
Change-Id: I4caadfb2feaf42ebb9f5578cb790ef8a1d08d173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095681
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66638}
When looking for private members in an object for the inspector,
we check if that object is a class constructor with the a bit
has_static_private_methods set on its SFI. If it
is, we look for any variables in the context locals
with a VariableMode associated with private methods or accessors
and a IsStaticFlag being kStatic.
This patch also filters out static private methods when inspecting
instances.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
See also: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit
Bug: v8:9839, v8:8330
Change-Id: Idad15349c983898de2ce632c38b0174da10e639d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955664
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#66636}
These two tests was fixed by ICU rolling to 0b6134378
See https://chromium-review.googlesource.com/c/chromium/src/+/2090002
File new bug 10313 to track the unrelated issue in
built-ins/Date/parse/without-utc-offset
Bug: v8:9612, v8:9474, v8:10313
Change-Id: I26f5857f3c4b6000b3585600bc3ed2f2ed29a043
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095394
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66635}
Bill kindly pointed out to me that v8windbg was not handling bit_field2
correctly. The issue was that the constexpr type for ElementsKind was,
somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
qualified type name like "v8::internal::ElementsKind". This change
addresses the problem in two ways:
1. Update v8windbg's type resolution logic to resolve type names as if
they were used in the v8::internal namespace. This makes it more
consistent with how those type names are used in other generated
Torque code, reducing surprises and the number of times we have to
write `v8::internal::` in .tq files.
2. Add compile-time verification that any constexpr type name used as a
string in class-debug-readers-tq.cc can also resolve as a type name.
Bug: v8:9376
Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66633}
When dst is a fp pair, we set both low and high fp regs. Later when we
look at set regs to determine which registers to load into, we examine
both low and high fp. This is wrong - we only need to look at the low
fp, since Fill will load into the correct fp pairs. The bug was
triggered because we were examining into junk values in register_loads
indexed by the high fp.
Fixed: v8:10307
Change-Id: I6cbc212a969090818a5da0fe3dab36a418c23d04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091632
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66632}
We now always tier down to Liftoff when the debugger is enabled, hence
we don't need to force Liftoff-only execution in the test.
R=thibaudm@chromium.orgCC=duongn@microsoft.com
Bug: v8:9654
Change-Id: I9b9e21b2ee977b349bb4f5d0e34c6ebf82166cb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093504
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66630}
This CL merges nested loops that share the same header offset with its
parent loop, by not emitting JumpLoop bytecode for these inner loops.
Instead, we generate a Jump to its parent's JumpToHeader (which in
turn can be a JumpLoop or another Jump to its parent's JumpToHeader).
Originally, every loop had a unique first Bytecode to jump to. Since
IterationBody StackChecks are going to become implicit this will no
longer be the case.
As a note, this CL just sets the foundation that the follow-up CLs
will build on top of. Since we have explicit StackChecks, and they
are at the beginning of loops we do not have nested loops as of now.
Bug: v8:10149, v8:9960
Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66626}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
In the process:
* Augment C++-generated Torque classes with SizeFor methods to
calculate size of instances.
* Add a new "@generateBodyDescriptor" annotation that causes Torque to
generate C++ BodyDescriptors code that can be used to visit objects
compatible with existing V8 mechanisms, e.g. GC
* Fully automate C++ macro machinery so that adding non-extern Torque
class doesn't require any C++ changes, including ensuring generation
of instance types and proper boilerplate for validators and
printers.
* Make handling of @export a true annotation, allowing the modifier to
be used on class declarations.
* Add functionality such that classes with the @export annotation are
available to be used from C++. Field accessors for exported classes
are public and factory methods are generated to create instances of
the objects from C++.
* Change the Torque compiler such that Non-exported classes implicitly
have the @generateBodyDescriptor annotation added and causes both
verifiers and printers to be generated.
* Switch non-extern Torque classes from using existing Struct-based
machinery to being first-class classes that support more existing
Torque class features.
Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66621}
The test started failing (sometimes flaking) on an unrelated CL.
R=gsathya@chromium.org
Bug: v8:10307
Change-Id: If198c2cf518f7a36e54614307462272774d9e48e
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091466
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66611}
This CL fixes a special case where a WasmExportedFunction is passed to
the WebAssembly.Function constructor. This is a case that was not yet
implemented in V8, and which is also not specified in the proposal yet.
With this CL we do a signature check of the provided function. If it
matches, the function itself is returned. Otherwise a TypeError is
thrown.
I filed an issue: https://github.com/WebAssembly/js-types/issues/13R=jkummerow@chromium.org
Bug: chromium:1057534
Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66610}
This is a reland of 79398ab09d
Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
> undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}
Tbr: ahaas@chromium.org
Bug: v8:10254
Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66598}
This reverts commit 79398ab09d.
Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186
Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
> undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}
TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org
Change-Id: Id80aa82cfce8942879031032b322ee66855b5600
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66597}
Also, save dynamic allocations (plus their memory overhead).
This is realized by storing the relocation information, source position
table, and protected instruction information together in one "metadata"
byte array.
For each of the three components, we just store their size, such that
the accessors can return the respecitive {Vector} views as before.
This makes each WasmCode object 24 bytes smaller on 64-bit
architectures. It also saves a few more bytes per code object because
less padding is needed for the individual allocations, and each dynamic
allocation comes with some constant memory overhead.
Since the protected instructions will just be stored in a byte array
now, some APIs are refactored to just return that byte array directly
(instead of an array of {ProtectedInstructionData}). This also
simplifies serialization and deserialization, and will allow for
switching to a more compact representation in the future.
Drive-by: Add some more checks to {Vector::cast} to protect against
undefined behaviour.
R=ahaas@chromium.org
Bug: v8:10254
Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66596}
This fixes a non-determinism issue caused by the cache being full.
Depending on the non-deterministic value of the handles in HeapConstant
nodes, different cache entries would be overwritten in this case.
The old implementation of NodeCache had a fixed limit, overwriting
entries when the cache is full. This behavior didn't really make sense,
but the hand-written hash map implementation couldn't handle arbitrary
numbers of hash collisions, so removing the limit wasn't an option either.
Thus this CL just replaces the custom hash map with a normal
std::unordered_map, that is, a ZoneUnorderedMap.
Bug: chromium:1046815
Change-Id: I95269f2b1068eb9dfe3ee2ab5cca1cb460bc8fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087405
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66592}
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by
taking advantage of SparseInputMask data structure to more quickly
handle empty inputs and insert all the OptimizedOut entries in one go.
The number of empty inputs is now determined using CountTrailingZeros
rather than iterating over them one at a time.
Gives a 9% improvement to SelectInstructions runtime call stat for
Octane in turboprop.
Bug: v8:10051
Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66591}
This is a reland of 9325397812
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
Bug: v8:10200
Change-Id: I5af003a06c60b0c8cd19de47f847a947d40d046c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082109
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66586}
This patch rolls v8 to the latest Perfetto revision. Since Perfetto has
changed the way the GN protobuf integration works, we need to make some
corresponding changes in V8.
Bug: chromium:639003
Change-Id: I263c591560503c9779bbab3ec266cfb2708fc51f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2085175
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66583}
When an empty class is nested inside a class with private instance
methods, like this:
class Outer {
constructor() {}
#method() {}
factory() {
class Inner {
constructor() { }
}
return Inner;
}
run(obj) {
obj.#method();
}
}
The bytecode generator previously generate private brand
initialization for the constructor of Inner by mistake,
because during scope chain serialization/deserialization,
the outer scopes of Inner and factory() are not allocated
or serialized (as they are empty). In the eyes of the bytecode
generator, it then appeared as if Outer is the direct outer
scope of Inner's constructor.
In order to work around this information loss, in this patch
we rely on SharedFunctionInfo instead of the Context/ScopeInfo
chain to maintain the information about private brand initialization.
This is done by shrinking expected_nof_properties to 8 bits and
freeing 8 bits for a second bitfield on the SFI.
Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
Bug: v8:9839, v8:8330, v8:10098
Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66575}
Remove Isolate parameters from some dictionary methods, and change
others to use ReadOnlyRoots instead, to prepare for Isolate
templatization in a future patch.
One small side-effect is that the global dictionary's property cell's
dependent code deoptimization has to dynamically get the Isolate when
it needs to actually mark code for deoptimization, for method signature
consistency. Given that this is the slow path anyway, it shouldn't
matter.
Bug: chromium:1011762
Change-Id: I707de9a74ca3b30423a1e5830a10729d6a404786
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080369
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66574}
Example can be inspector tests.
Bug: v8:10264
Change-Id: I996bb68d0f36920568a04f93cd8c1256a4f41a96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070912
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66572}
Move the recently introduced extra check for 32-bit platforms so
that it covers all code paths that would be hit by custom/future
memory limit settings.
Bug: chromium:1057094
Change-Id: I5e2217a24578ee82c7bfa753b7d5dcd3d00e1b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083300
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66568}
Report the total size of global handles in GetHeapStatistics as well.
This size includes used and free global handles.
Change-Id: I08c0647d993a810a37ae9f332732de9551b5ea8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083020
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66562}
The scope disables garbage collection and should be only used in
heap, deserializer, isolate bootstrap, and testing.
Change-Id: Ide95926ef32fd9362cd9134e883e1bd626cc3b11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083292
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66557}
This is a reland of c6c9d4bf1b
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
Bug: v8:10120
Change-Id: Ib2ee68e26c2aebe2eeab3ec9f7bc263fd79f3773
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083291
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66550}
The spec was changed in February TC39 to make ToInteger always normalize
-0 to +0. This only observably affects Atomics.store.
Bug: v8:10271
Change-Id: I0e8f6c35cef982eae242cf6619f6f24fa75b1759
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076509
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66543}
Some opcodes are introduced in V8 for prototyping, and performance
measurements that are not officially a part of the current SIMD proposal
but may be included in future, gate these by a separate flag.
Change-Id: Icc6a9e89c6196c8ff144d2e0193d707e1f60c38b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079539
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66542}
This is a reland of 25d16574f8
Changes from original: replaced slow test with fast test
Original change's description:
> [runtime] Improve handling of enumeration index on global dictionary
>
> Bug: chromium:1056054
> Change-Id: Ie1f2da98bc54a2ad5189cbe2ee1686fe1ef7019a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079035
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#66504}
Bug: chromium:1056054
Change-Id: I45b9a096b1e37bf1dc5e792f106cdfadd47fabf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080855
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66535}
This reverts commit c6c9d4bf1b.
Reason for revert: Fails on noi18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/30737
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
TBR=jkummerow@chromium.org,jgruber@chromium.org
Change-Id: I960b90fe3679ef4c04782ca9ac9b91454e636dbb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083024
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66525}
There appear to be one or several bugs in noi18n mode such that
expectations in this test are no longer met. This CL updates
expectations to the current behavior and re-enables the test so we at
least preserve coverage in the other cases.
The behavior in question should be investigated in the future
(low priority).
Bug: v8:10120
Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66524}
In the past we've used the isolate argument to signal whether we were
in unicode mode (nullptr) or not (the real isolate). This is no longer
needed, and in fact breaks no-i18n mode which always expects to have a
real isolate.
Bug: v8:10120
Change-Id: I2f848c4ff8c2ff0e9b84278cbcdf3c3670e44e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081816
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66520}
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and
make the OffThreadIsolate allocate "real" Handles. Rather than using
the main-thread Isolate's handle scopes, these off-thread Handles are
backed by a Zone, which is tied to the lifetime of the nearest
OffThreadHandleScope. Eventually, we'll likely want to merge the
implementation of OffThreadHandleScope and HandleScope, but currently
the latter is too tightly coupled to the main thread to do so.
Bug: chromium:1011762
Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66516}
We can make better inlining decisions in TurboFan if the CallIC will
provide the feedback that it's seen multiple closures that share the
same SharedFunctionInfo. This is not difficult to do, and it fixes
some frustrating performance cliffs.
Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his
project a year ago.
Bug: v8:2206, v8:10100
Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66512}
This reverts commit 9325397812.
Reason for revert: Causing blink layout failures. See
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Future/2684
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
TBR=verwaest@chromium.org,timothygu@chromium.org,syg@chromium.org
Change-Id: I81737750f8b369567ba586c5a2cfb489836b7e74
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10200
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081091
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66510}
When a microtask is executed, we need to use an appropriate,
non-detached Context for its execution. Currently with
PromiseResolveThenableJobs [1], the Context used is always drawn from
the realm of the Promise constructor being used. This may cause
non-intuitive behavior, such as in the following case:
const DeadPromise = iframe.contentWindow.Promise;
const p = DeadPromise.resolve({
then() {
return { success: true };
}
});
p.then(result => { console.log(result); });
// Some time later, but synchronously...
iframe.src = "http://example.com"; // navigate away.
// DeadPromise's Context is detached state now.
// p never gets resolved, and its reaction handler never gets called.
To fix this behavior, when PromiseResolveThenableJob is being queued up,
the `then` method of the thenable should be used to determine the
context of the resultant microtask. Doing so aligns with Firefox, and
also with the latest HTML spec [2][3].
This change is analogous to CL 1465902, which uses the realm of the
reaction handlers to determine the Context PromiseReactionJobs run in.
[1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
[2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
[3]: https://github.com/whatwg/html/pull/5212
Bug: v8:10200
Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66507}
Previously, our Torque definition of JSArrayBuffer included only the
first two fields. This allowed access to those two fields, but was
somewhat confusing and obviously didn't let Torque code access the
other fields. This change:
- Completes the JSArrayBuffer layout definition;
- Moves the associated bitfield struct definition to Torque;
- Moves a couple of JSArrayBuffer macros to Torque;
- Adds a reducer case so that the code generated using these new macros
is not worse than what was generated previously.
Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66503}
There were a few places that still checked against the limit for
initial memory size rather than the limit for memory size after
growth (which was recently separated from the former).
Bug: v8:7881
Change-Id: Id17d86e2f7a5dfa4f1dd35153b0cefc01f72ed33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078574
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66496}
Port 6cd28b522a
Original Commit Message:
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
compilation by using alternative temp register for x64.
macro assemblers.
R=ecmziegler@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ib08e31dfa11f0254c7888ce17dd27e7d0154c752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078898
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66490}
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
Drive-by: Fixed issues with kScratchRegister being overwritten in case of RegExp
compilation by using alternative temp register for x64.
Drive-by: Added missing NoRootArrayScope to ia32, arm and arm64 RegExp
macro assemblers.
R=clemensb@chromium.orgR=petermarshall@chromium.orgR=jgruber@chromium.org
Bug: chromium:1045860
Change-Id: I716d852b9bf780ae7b8d61376c6505dd3af96a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071866
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66482}
Most function signatures are created once and never changed. Hence pass
them as const pointer. This makes it clear in function signatures that
these parameters will not be modified.
This also avoids a few ugly const_casts where we were passing pointers
to constexpr FunctionSigs via non-const pointers.
R=jkummerow@chromium.org
Bug: v8:10155
Change-Id: Ieb658ab5582bff276f76babdaf7ddb8f72bd4790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072739
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66478}
This is a reland of 7d1f95d6e4
The reland fixes a performance issue in that we incorrectly marked
every pattern containing a backslash as needing to be escaped,
resulting in a new string allocation instead of reusing the existing
string.
Original change's description:
> [regexp] Correctly escape a backslash-newline sequence
>
> When printing the source string, a backslash-newline sequence ('\\\n',
> '\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
> '\u2028', '\u2029', respectively. Prior to this CL it was formatted as
> a backslash followed by the literal newline character.
>
> Bug: v8:8615
> Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65986}
Bug: v8:8615,chromium:1046678
Change-Id: I5d75904f1ea543ec679649668e54749821116442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074159
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66476}
This reverts commit 4dc1fb4e04.
Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
Original change's description:
> Revert "[torque] Support bitfield structs stored within Smis"
>
> This reverts commit e5e4ea962e.
>
> Reason for revert: mysterious performance regression chromium:1052756
>
> Original change's description:
> > [torque] Support bitfield structs stored within Smis
> >
> > This change moves the definition of the bits stored in DebugInfo::flags
> > to Torque, and updates the only Torque usage of that field to use more
> > natural syntax. This is intended as an example of common patterns found
> > in various other classes. Several supporting changes are required:
> >
> > 1. Add a new type representing a bitfield struct stored within a Smi. It
> > is currently called SmiTagged, but I'm open to suggestions.
> > 2. Add an enum-style output for Torque bitfield structs whose bitfields
> > occupy only one bit each.
> > 3. Add a new case to MachineOperatorReducer that makes the generated
> > code for IncBlockCounter match with what was generated before this
> > change.
> > 4. Add support for reporting these bitfields in the postmortem debugging
> > API. The format matches existing bitfields but with an offset value
> > that includes the SMI shift size.
> >
> > Bug: v8:7793
> > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66182}
>
> Bug: chromium:1052756, v8:7793
> Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66349}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1052756, v8:7793
Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66465}
Before: running different suites is removing non-related master data
After: different suites have separate master data files
Change-Id: Iab46d663fdf2a1d709aeb7da77a443c2ed1bdcc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071870
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Marcin Wiącek <marcin@mwiacek.com>
Cr-Commit-Position: refs/heads/master@{#66453}
This reverts commit b12ba06edf.
Reason for revert:
After further discussion we decided to stick with fdlibm.
Original change's description:
> [builtins] stop using imprecise fdlibm pow
>
> This CL reinstates the old pow implementation which calls out to the
> system implementation of pow.
>
> Bug: v8:9622
> Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66303}
TBR=yangguo@chromium.org,neis@chromium.org,hpayer@chromium.org,me@gus.host
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9622
Change-Id: I941f70c7432cd2fab86e0eadcb2e1a9ec8195e91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072746
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66452}
Added a type field to elements to distinguish anyref, funcref and
nullref elements and do a proper type checking at compile time as
the spec requires.
R=ahaas@chromium.org
Change-Id: I31be7aa1170439859ca7ec5e20aabb2720c290b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069330
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66448}
Move load splat and load extend ops into the list of SIMD memory
opcodes, since they similarly take an i32 and an memarg. This fixes the
OpcodeLength calculation in function-body-decoder-impl.h.
And in turn, fixes the mjsunit test code that the fuzzer generates. See
the regress-1055692.js file for the weird S8x16LoadSplat followed by 2
kExprUnreachable, where the kExprUnreachable really is a memarg
{0x0, 0x0}. This bug was caught by the fuzzer, and that was the
generated test (with small fixes to add kExprDrop), so leaving it as it
is.
Bug: chromium:1055692
Change-Id: I743b6beb82350b5fea22c8dd10b546a02741cfed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071401
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66439}
FMA tests that are running on Liftoff can use fused results, since the
tests will fall back to TurboFan.
Bug: v8:9415
Change-Id: I02edea5ce1447263f7bc7574573418b0055aef8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063202
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66438}
The deprecated legacy FinalizationGroup APIs are left unchanged for
compat.
Bug: v8:8179
Change-Id: I9bdcaa92360db318c96fc8524c04163ece25118e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071236
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66437}
We want to be consistent with wasdk/wasmparser.
The names used in V8 should follow the WAT convention and always start
with a dollar, both for names from the "names" section as well as
generated names.
Bug: v8:10242
Change-Id: If4dbd4c38208c9dd9377dd2f79120635a531d881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070637
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66434}
This extends the existing test to also print scope information on every
break. Note that the currently printed information is not correct, since
register values are not reconstructed yet. We just always print {-11}
for register values.
Thus the expected output will change with follow-up CL.
R=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I7be13ecb02957454c875a4280cec154a08c2deb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062403
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66433}
This is a reland of 03d5a7ba9b
Nothing changed here compared to the original test. The tests on the
blink side were invalid, I fixed them in https://crrev.com/c/2066907.
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
Bug: v8:10126
Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66431}
We use the same interrupt to both allocate feedback vectors and
for updating the profiler ticks. If there is a feedback vector already
available, we just increment the profiler ticks that we use to mark
for optimizing function. Calling JSFunction::EnsureFeedbackVector
allocates a feedback vector, but doesn't reset the budget, so we
optimize much earlier than expected. This is currently only a problem
with %PrepareFunctionForOptimize that doesn't reset the budget. Other
code paths do also reset the interrupt budget.
Bug: chromium:10243
Change-Id: I611a9202e5e71077bf897def5959bcfe11b8fdf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064980
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66426}
This is a reland of 78defee492
Original change's description:
> [inspector] Check that wasm wrappers appear in profiles
>
> This extends the existing wasm profiling test to also check that
> wasm-to-js and js-to-wasm wrappers appear in the profiles as expected.
> It thus serves as a regression test for the status quo.
>
> R=bmeurer@chromium.org
>
> Bug: chromium:1054386
> Change-Id: I5d4d8e6a252c6eb266b910621fca43a6ff0837bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066970
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66401}
TBR=bmeurer@chromium.org
Bug: chromium:1054386, v8:10266
Change-Id: Iae04c0564ee8f0330d61ce954d895a41497c5a85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071260
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66424}
This is a reland of 548fda4afb
regress-1054466 is modified to not use 64x2 operations, since that was
causing problems on noavx/nosse builds, which requires scalar lowering,
and scalar lowering for 64x2 ops is not implemented.
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
Bug: chromium:1054466
Change-Id: If88f1ff2fb17aaa3727758cda5b368be1c6d9bd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071396
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66423}
This CL generalizes the lowering of special CallDescriptors in the
int64-lowering. The reason is a planned extension of the special
handling due to a refactoring of the AtomicWait implementation.
R=jkummerow@chromium.org
Bug: v8:10108
Change-Id: I48d0087e2ad00ba9b44c5198ffdbbae8eb575a85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069333
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66420}
Renaming the JS-visible identifiers and strings is left for a future CL.
FinalizationGroup was renamed at Feb 2020 TC39, to better signal that if
a FinalizationRegistry dies, the finalization actions registered with it
may no longer be performed.
Bug: v8:8179
Change-Id: I0d676a71a4a67d2b7175994a67458a6158065844
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055381
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66416}
Changes the lambda capture for this test so that referenced variables
are captured automatically. This means MSVC and Clang can compile the
same test without compiler-specific #ifdef's.
Bug: v8:10012
Change-Id: Ife4ee050e227478842c0f8def92adb0857082ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066984
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66414}
Currently implicit returns do not correctly resolve the async generator
objects. This is observable via AsyncGenerator#throw as the implicit
return won't override the rejection.
Bug: v8:10238
Change-Id: I012fc3507d1e4106e7f35b21275be180a6e274c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065343
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66413}
This will enable people to check if an object is
document.all without having to use tricks like
`typeof v === 'undefined' && v !== undefined`.
Change-Id: I74670e4d3886fcd90f0f3cef9c3644a24ee08fda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2067681
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66412}
This reverts commit 827107a7dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1054664
Original change's description:
> [wasm-debug] Let wasm scripts report correct column information.
>
> In the debugger, wasm scripts currently do not contain meaningful column
> informations. Fix that by keeping track of the offset and size of the
> wasm code section inthe module and reporting that to the debugger.
>
> Bug: chromium:1042636
> Change-Id: Ie2b5d3a50952a467d256f815c16e459cb0ae600e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011083
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65913}
Bug: chromium:1042636
Change-Id: Ic59d71111c3274688828bdbf6894f7f3274dc50a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066983
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66409}
This extends the debug side table to also store register locations in
addition to constants and stack values.
Previously, every value that was not constant was assumed to be spilled
to the stack. This made sense, because without breakpoints we would only
emit debug side table entries at call sites, where all registers are
spilled.
With breakpoints, this changes. At break locations, values might be live
in registers.
The logic to decide whether a value will live in the register or on the
stack is extended, because we sometimes generate the debug side table
entry at a point where the registers are not spilled yet. The debug side
table entry creation needs to account for that, and assume that these
registers will still be spilled.
R=thibaudm@chromium.org
Bug: v8:10147, v8:10222
Change-Id: I3b020dfaa29fc007047663706ee286180a996bfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066960
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66407}
This reverts commit 78defee492.
Reason for revert: Timeout on TSan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/30410
Original change's description:
> [inspector] Check that wasm wrappers appear in profiles
>
> This extends the existing wasm profiling test to also check that
> wasm-to-js and js-to-wasm wrappers appear in the profiles as expected.
> It thus serves as a regression test for the status quo.
>
> R=bmeurer@chromium.org
>
> Bug: chromium:1054386
> Change-Id: I5d4d8e6a252c6eb266b910621fca43a6ff0837bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066970
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66401}
TBR=clemensb@chromium.org,bmeurer@chromium.org
Change-Id: Iac4299d5a4dc74041fbceac98cd2c2b96b9425df
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1054386
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069328
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66406}
This reverts commit 548fda4afb.
Reason for revert: Segfault on nosse bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/35905?
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I56f13406ef3cc3793c9d0e2273c4dc5fb0e3de38
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1054466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069327
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66405}
Given two registers that are both not gp_pair, one could be an fp_pair,
and the other not, and we will incorrect call == on them. The current
check needs to be expanded to check that both registers are fp_pair.
Bug: chromium:1054466
Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66402}
This extends the existing wasm profiling test to also check that
wasm-to-js and js-to-wasm wrappers appear in the profiles as expected.
It thus serves as a regression test for the status quo.
R=bmeurer@chromium.org
Bug: chromium:1054386
Change-Id: I5d4d8e6a252c6eb266b910621fca43a6ff0837bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066970
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66401}
Make sure the "initial pages" memory limit is enforced correctly and
throws a CompileError when exceeded.
Bump the "maximum pages" memory limit to 65536.
The --wasm-max-mem-pages flag now controls the "initial pages" limit;
the "maximum pages" limit is always 65536 as spec'ed.
This CL depends on https://github.com/WebAssembly/spec/pull/1121.
Bug: v8:7881, v8:8633
Change-Id: I68d07cef56633b8b8ce3b3d047c14e1096daf547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035876
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66400}
Relanding the Fast C API code with fix for UBSan undefined behavior
issue.
Design doc:
http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/
This CL implements basic API with integer and pointer types marshaling.
What is not supported yet:
- sequences
- annotations
- floating point arguments
- 64-bit arguments
- exception handling
- InstanceOf checks for the pointer types
- functions with non-void return type
Bug: chromium:1052746
TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org
Change-Id: Ifca9de3156cf18c9dac0d14c19f8d6a7004cad83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066971
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66391}
After support for ARCH_PPC was dropped, it became a subset of
ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64
define which also sets the ARCH_PPC define.
To be able to again support ppc (32 bit) those defines should be
split up again.
This commit only splits up the defines but does not introduce a
working ARCH_PPC variant.
Bug: v8:10102
Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66390}
Jitless mode does not allocate executable memory, so we can avoid reserving
memory in such configurations.
Bug: v8:10033
Change-Id: Ie6a943084e3bade85848e3219cb4d8779ed34830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981505
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66388}
This extends the debug side table test to check that the two methods
{ExecuteLiftoffCompilation} and {GenerateLiftoffDebugSideTable} return
the same debug side table.
This is important, because for code without breakpoints, we generate the
debug side table lazily via the {GenerateLiftoffDebugSideTable} method,
and it needs to match the code generated previously via
{ExecuteLiftoffCompilation}.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: I267f599beb3fe39a1ccf22840a9d0a7f9bc5143e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066957
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66384}
The AVX versions of pabsb, pabsw, and pabsd have an incorrect function
signature, they should only have two operands. So, extract them into
another macro list. And separately generate the right signatures and
implementations. Also update the disasm and tests.
Bug: v8:10233
Change-Id: I95ee0bf12bb285d10324ecedcec28e941f64d2dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063199
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66382}
Implements lowering for:
- i16x8.load8x8_s
- i16x8.load8x8_u
- i32x4.load16x4_s
- i32x4.load16x4_u
As before, i64x2 is not implemented since 64-bit lowering and scalar
lowering don't work together yet.
Bug: v8:9886
Change-Id: I3728d009e053acf82baacbcf1c6c08ea636ef241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044546
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66380}
This is the first piece of the wasm debugging prototype (besides the changes to
add/remove breakpoints in WasmModuleObject made with
e699f39cae).
This changelist adds the infrastructure for a GDB-remote stub that will be used
to manage debugging sessions via the gdb-remote protocol.
It enables the creation and termination of debugging sessions over TCP
connections that are managed in a separate thread.
The logic to actually send, receive and decode GDB-remote packets will be part
of a future changelist.
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with:
--wasm-gdb-remote Enables Wasm debugging with LLDB
(default: false)
--wasm-gdb-remote-port TCP port to be used for debugging
(default: 8765)
--wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting
for a debugger (default: false)
--trace-wasm-gdb-remote Enables tracing of Gdb-remote packets
(default: false)
Note that most of this code is "borrowed" from the code of the Chromium NaCL
GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub).
Implementation details:
- class GdbServer acts as a singleton manager for the gdb-remote stub. It is
instantiated as soon as the first Wasm module is loaded in the Wasm engine.
- class GdbServerThread spawns the worker thread for the TCP connection.
- class Transport manages the socket connection, in a portable way.
- class Session represents a remote debugging session.
- class Target represents a debugging target and it’s the place where the
debugging packets will be processed and will implement the logic to debug
a Wasm engine.
Bug: chromium:1010467
Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66379}
An enum cache can only be referenced together with the map that owns the
entries that are needed. Otherwise the entires can be trimmed away if
the map dies because of transitions.
Bug: chromium:1050046
Change-Id: I5bc9dd65ca092c3d5ebc08ce553f6f1dc980d41b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066959
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66375}
This refactors the debug side table such that we can easily add
register information later.
In particular
- vectors for types and stack offsets are combined into one;
- constants are stored in the same vector;
- locals and operand stack values are stored in the same vector.
A follow-up CL will extend the DebugSideTable to also encode locals
or operand stack values held in registers.
R=thibaudm@chromium.org
Bug: v8:10147, v8:10222
Change-Id: I97adb56b31afdb22896530c7ba2e8a24b5d31da9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062405
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66374}
This fully tnodifies TryHasOwnProperty, TryLookupProperty,
CheckPrototypeEnumCache, CheckEnumCache and
ExtractFixedDoubleArrayFillingHoles.
CopyElementsOnWrite is also converted except for parameters passed with
ParameterMode.
Also fixes the type of TryLookupProperty, which fails tests if the
object parameter is actually forced to be JSReceiver.
Bug: v8:10155
Change-Id: I3a925f1fd3f8a1b610d63d08a49af48ef6da505c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064979
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66373}
Add a test case to ensure that a wasm stack trace prints the
source url if it is available.
Bug: v8:9762
Change-Id: If44f440529d6017d08e477aa03328c9f40f4244c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064215
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66363}
This can speed up the below micro-bench by 3x and improve JetStream2-tagcloud-SP case by ~2%.
Object.prototype.foo = function() {};
let array = ['a','b','c','d','e'];
let start = Date.now();
for (let i = 0; i < 1e5; i++) {
for (let j in array) {}
}
console.log(Date.now() - start);
Contributed by tao.pan@intel.com
Change-Id: I44c948c2e4c28b8e42192f36802a5ea0f82bbe25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049903
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Cr-Commit-Position: refs/heads/master@{#66362}
Converting from Uint32Array to Uint8Array will have"0"
set as the first byte on BE machines:
[0,0,AB,CD]
Using Uint16Array will produce the correct result:
[AB,CD]
Change-Id: I9069f14c60a088a52af6d287c88be4ad437ee04d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064528
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66357}
This reverts commit 03d5a7ba9b.
Reason for revert: Needs rebaseline:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66356}
After compiling a function with a different set of breakpoints, update
return addresses on the stack so that execution resumes in the new
code.
This allows new breakpoints to take effect immediately, which is the
expected behavior and a prerequisite for stepping.
R=clemensb@chromium.org
Bug: v8:10147
Change-Id: I67eb3b4ce23a1f3b0519935447f8b847ec888ead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064218
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66351}
This reverts commit e5e4ea962e.
Reason for revert: mysterious performance regression chromium:1052756
Original change's description:
> [torque] Support bitfield structs stored within Smis
>
> This change moves the definition of the bits stored in DebugInfo::flags
> to Torque, and updates the only Torque usage of that field to use more
> natural syntax. This is intended as an example of common patterns found
> in various other classes. Several supporting changes are required:
>
> 1. Add a new type representing a bitfield struct stored within a Smi. It
> is currently called SmiTagged, but I'm open to suggestions.
> 2. Add an enum-style output for Torque bitfield structs whose bitfields
> occupy only one bit each.
> 3. Add a new case to MachineOperatorReducer that makes the generated
> code for IncBlockCounter match with what was generated before this
> change.
> 4. Add support for reporting these bitfields in the postmortem debugging
> API. The format matches existing bitfields but with an offset value
> that includes the SMI shift size.
>
> Bug: v8:7793
> Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66182}
Bug: chromium:1052756, v8:7793
Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66349}
The WebAssembly spec defines that the name of a custom section can cause
a validation error. The streaming decoder, however, used a separate
Decoder object to decode the name, and thereby avoided a validation
error. With this CL the streaming decoder uses the main decoder to
decode the name of the custom section.
In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
This test defined an invalid WebAssembly module and expected it to
compile. As it is a regression test, it makes no sense to fix the test.
The module is invalid because it defines the length of the custom section
to be '0', so there are no bytes in the custom section for its name.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10126
Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66348}
This reverts commit 4e11ad92f3.
Reason for revert: Signed int overflow in TestFastApiCalls in UBSan https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/9976
Original change's description:
> [turbofan] Fast API calls from TurboFan
>
> Relanding the Fast C API code with fix for arm sim lite build.
>
> Design doc:
> http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/
>
> This CL implements basic API with integer and pointer types marshaling.
>
> What is not supported yet:
> - sequences
> - annotations
> - floating point arguments
> - 64-bit arguments
> - exception handling
> - InstanceOf checks for the pointer types
> - functions with non-void return type
>
> Bug: chromium:1052746
>
> TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org
>
> Change-Id: I4421ce817e3b6159a38d2cb39fb97847f128e648
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064223
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66344}
TBR=mvstanton@chromium.org
Change-Id: I63bde3e0b7f92506fd8ec6d39683524bc9811aa6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1052746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062739
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66347}
Regrettably the previous fix was flawed because a zero increment can
change the type of the induction variable.
Bug: chromium:1051017
Change-Id: I2d7aeffb2065e739445118a2d0c5f7732eecdcbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064222
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66345}
Relanding the Fast C API code with fix for arm sim lite build.
Design doc:
http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/
This CL implements basic API with integer and pointer types marshaling.
What is not supported yet:
- sequences
- annotations
- floating point arguments
- 64-bit arguments
- exception handling
- InstanceOf checks for the pointer types
- functions with non-void return type
Bug: chromium:1052746
TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org
Change-Id: I4421ce817e3b6159a38d2cb39fb97847f128e648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064223
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66344}
Whenever we use an "arrayType" that is stored as multiple bytes,
the host machine's endianness becomes apparent in the result.
This Cl adds the functionality to check the result based on the
host machine's endianness.
Change-Id: Ie96e8dd04b7e209127eff67ee06e1fa0ee5bc290
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063861
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66343}
This changes many functions in code-stub-assembler.h to pass or return
TNode parameters rather than Node*. In general these are functions that
take ParameterMode and so optionally pass IntPtrT or Smi in a Node which
cannot be easily fixed so these parameters and are left alone.
Also move StoreFixedArrayOrPropertyArrayElement into the private section
of CodeStubAssembler's class definition.
Bug: v8:10155
Change-Id: I010a928cecf105bcf9a5e9f86a402e47733ba7f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2059994
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66340}
Since liftoff is turned on upon debugger.enable, these tests need to be
skipped.
Change-Id: Icaa02ffb77d0bbcb24b2c232e519c0547e714a24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062940
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66335}
There are cases where we push FP and LR to the stack even though we have
already created a frame and already stored them.
Avoid doing this, by cleaning up the caller- and callee-saved
register lists, and passing a LinkRegisterStatus argument to
TruncateDoubleToI.
Change-Id: I652e7ec346a99e94617f1ec6b13935f5d2f73e7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060505
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66330}
JSCreate can have side effects (by looking up the prototype on an
object), so once we walk past that the analysis result must be marked
as "unreliable".
Bug: chromium:1053604
Change-Id: I36625b14f374e74561c9b539bdf7a02ae767cf7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062396
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66329}
In the spec, WeakRefs that are dereferenced are kept alive until there's
no JS on the stack, and then the host is expected to call
ClearKeptObjects to clear those strong references [1]. HTML calls
ClearKeptObjects at the end of a PerformMicrotaskCheckpoint [2].
In V8, leaving this up to the embedder is error prone in the same way
the deprecated FinalizationGroup callback APIs were error prone: it
depends on the embedder doing the right thing. This CL moves the call to
ClearKeptObjects to be after running of microtasks within V8.
However, the Isolate::ClearKeptObjects API should not be removed or
deprecated in case an embedder uses an entirely custom MicrotaskQueue
implementation and invokes MicrotaskQueue::PerformCheckpoint manually.
[1] https://tc39.es/proposal-weakrefs/#sec-clear-kept-objects
[2] https://github.com/whatwg/html/pull/4571
Bug: v8:8179
Change-Id: Ie243804157b56241ca69ed8fad300e839a0c9f75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055967
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66327}
This is still very limited, but we will have some simd instructions.
We add 2 kinds of instructions:
- any_true to generate i32 from v128
- add to generate v128 from v128 and v128
- extract_lane to generate v128 from all other types
We do not add v128 to the list of types returned by GetValueType, since
that is used in a couple of places, like generating globals, which
requires v128.const but is not implemented yet.
Special case to enable the experimental-wasm-simd flag since simd is not
included in wasm-staging yet.
Bug: v8:10180
Change-Id: Ifd86f55bdd49cae9514b061965de81ff6d579934
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2040514
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66326}
Store a flag per isolate whether new modules should be kept in
tiered-down state from the beginning. Adjust initial compilation if flag
is set.
Bug: v8:9654
Change-Id: I5aae435fb807f3eaa7efafe9af60451ad3c7e14d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028452
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66321}
When running microtasks, the auto policy currently only invokes
MicrotasksCompletedCallbacks when the microtask queue is non-empty,
while all other policies unconditionally invokes the callbacks. Make the
auto mode also unconditionally invoke the callbacks.
Bug: v8:10213
Change-Id: I2f608459960b84e6f506646712ac935130646b9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2057813
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66320}
Please take a look at tools/v8windbg/README.md for an overview of what
v8windbg can do and how it's structured. This platform-specific
debugging plugin makes use of the data provided by the V8 postmortem
debugging API in tools/debug_helper.
Note: This code began as https://github.com/billti/v8dbg and then moved
into the Edge repository, where I added features gradually and got code
reviews for individual changes. Now, taken in its entirety, it's an
obnoxiously large CL. I'm open to breaking it up into a few chunks if
that would be preferable.
Bug: v8:9376
Change-Id: I3e503de00bb1aea870ae83e9bd99e4e2eab9ef98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031700
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66319}
Fix the gc_stress problem in Original by moving the
NewStringFromAsciiChecked before the cast.
This is a reland of a872c393c6
Original change's description:
> [Intl] Fix RelativeTimeFormat fatal
>
> Intl.RelativeTimeFormat constructor crash while the locale or
> numberingSystem contains an "algorithmic" numberingSystem.
> Fix by fallback to the locale without the nu
>
> Bug: chromium:1041319
> Change-Id: Ica520e8dec6ace21264504274b92cb2c3d16286f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055970
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66276}
Bug: chromium:1041319
Change-Id: I97563c5dbac1842a4e740e2450070471ea2681a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2057761
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66315}
... in favor of CodeAssembler's ScopedExceptionHandler.
Also remove unused exception arguments from some iterator
related methods.
Bug: v8:10187
Change-Id: I8eb7dfd4eb339e4f566970efa5757c3771926ba6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060496
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66306}
This adds tests for the mock logic used in differential fuzzing. The
tests uncovered a couple of issues in the mock files that are also
fixed.
This also does some minor code clean up in the mock code.
Bug: chromium:1044942
Change-Id: I5b67f70f8b104bb681548f742ab863395a88360f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043843
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66304}
This CL reinstates the old pow implementation which calls out to the
system implementation of pow.
Bug: v8:9622
Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66303}
REPL 'let' declared variables use VariableLocation::REPL_GLOBAL which
was not handled by a switch in the bytecode generator. The default
case ran into an UNREACHABLE.
This CL fixes this by properly handling VariableLocation::REPL_GLOBAL
for delete.
Drive-by: Replaced the default case with an explicit case for
VariableLocation::MODULE.
Bug: chromium:1052721
Change-Id: I1330ff2f2c6f042a596a8298599a5d58769894f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060488
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66301}
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex,
we get back one bit that we can use to increase the number of hash bits
stored. The price is that strings that represent array/integer indices
beyond the cacheable range will have to be scanned more often, but these
strings should be rare, and we expect that the additional hash bit is
more worthwhile to have.
Bug: v8:9904
Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66299}
Implement the latest spec changes:
- Allow declarative segments to behave like passive & dropped segments.
- Enforce that only declared functions may be returned or used in globals
as funcref.
- Ensure that table fill does not modify any entries if OOB.
Spec tests for select and br_table are still failing due to proposal issue
Bug: v8:10156
R=ahaas@chromium.org
Change-Id: I5b95be36a67bc7482a84b848908cc4cbdf94af03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027458
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66297}
Intl.RelativeTimeFormat constructor crash while the locale or
numberingSystem contains an "algorithmic" numberingSystem.
Fix by fallback to the locale without the nu
Bug: chromium:1041319
Change-Id: Ica520e8dec6ace21264504274b92cb2c3d16286f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055970
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66276}
Since the size of the parameters and locals inputs is already stored on
the FrameStateFunctionInfo, this skips the calls to size() and just
reuses the previous values. The stack parameter can only have a size of
0 or 1 depending on whether it's a InterpretedFunction frame or not.
It also extends the verifier to check that the values to match those
returned by StateValueAccess::size and changes a unit test that added
a TypedStateValues of size 2 to the stack input.
Bug: v8:10051
Change-Id: I3693c04b4677812b9f19491c198d0551df20f817
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047045
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66268}
The previous code was relying on {compilation_unit_builder_} to check if
a section was after or before the code section. This only works for the
first section after code section, since the compilation unit builder is
then reset. Use an additional field to track this instead.
R=clemensb@chromium.org
Bug: chromium:1051912
Change-Id: Id1dfa803ecde2cf77f206ea781c007fc61168942
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054099
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66265}
These tests are likely missing %PrepareFunctionForOptimization
annotation of lambdas. Thus lambdas are no longer inlined and
%DeoptimizeNow does nothing, while the entire point of these tests is
to test deoptimization paths.
Disabling lazy feedback allocation is a quick fix to restore coverage
until we can land a more complete fix (for details see the linked
bug).
Bug: v8:10195
Change-Id: I4038cdc5718230253ffb5bbc57d574342c652377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054096
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66261}
The fix in b8b6075021 was insufficient.
The bug is that induction variable typing does not take into account
that the value can become NaN through addition or subtraction of
Infinities. The previous fix incorrectly assumed that this can only
happen when the initial value of the loop variable is an Infinity.
Bug: chromium:1051017
Change-Id: I8c9ffb2925288b80c00e18e7bc22a556bf540733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051957
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66258}
This is a reland of 137bfe47c9
Original change's description:
> [arm64] Protect return addresses stored on stack
>
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack. The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
>
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
>
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
>
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}
Bug: v8:10026
Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#66254}
A FinalizationGroup that needs cleanup should not artificially prolong
its lifetime by being on the dirty list.
R=ulan@chromium.org
Bug: v8:8179
Change-Id: I19f102d154a9ac43b549b7d833d0c3ca7e61c6d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051562
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66251}
Fuchsia's SDK will soon provide GN rules include one for declaring
fuchsia package targets. Since the SDK-provided rule works differently
from the Chromium one but is called fuchsia_package(), we need to rename
the Chromium rule to avoid them clashing.
Bug: chromium:1050703
Change-Id: Ia2fcba8e32f311e6859590d9c95730ffe6875192
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050388
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66244}
This reverts commit 137bfe47c9.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
Original change's description:
> [arm64] Protect return addresses stored on stack
>
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack. The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
>
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
>
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
>
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}
This change uses the Arm v8.3 pointer authentication instructions in
order to protect return addresses stored on the stack. The generated
code signs the return address before storing on the stack and
authenticates it after loading it. This also changes the stack frame
iterator in order to authenticate stored return addresses and re-sign
them when needed, as well as the deoptimizer in order to sign saved
return addresses when creating new frames. This offers a level of
protection against ROP attacks.
This functionality is enabled with the v8_control_flow_integrity flag
that this CL introduces.
The code size effect of this change is small for Octane (up to 2% in
some cases but mostly much lower) and negligible for larger benchmarks,
however code size measurements are rather noisy. The performance impact
on current cores (where the instructions are NOPs) is single digit,
around 1-2% for ARES-6 and Octane, and tends to be smaller for big
cores than for little cores.
Bug: v8:10026
Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}
We were calling setup for both the setup and the run.
Bug: v8:10155
Change-Id: Id60df16ad8c98f443dc1b1a9a2155000999ab815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039431
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66234}
These tests rely on predictable opt & deopt timings. Also add the
--opt flag to tests to force optimization even in configurations that
contain the --no-opt flag.
Bug: v8:9972,chromium:1049982
Change-Id: Ic161d188ebfae9aaae6a160d365413abedfee5f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050402
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66231}
This CL introduces, and turns on by default, compression for snapshots.
The compression is handled in SnapshotCompression, which is a new static
helper class for producing/consuming compressed SnapshotData.
To turn off snapshot compression (accomplished by removing calls of
Compress/Decompress) set the GN arg:
v8_disable_snapshot_compression = true
Bug: chromium:833361
Change-Id: If8abc3662e8473fbd0c94e443946fbea804a305e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846066
Commit-Queue: Sam Maier <smaier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66230}
It's not sufficient to reset only the modules on the current DFS path.
Bug: chromium:1050164
Change-Id: I00e5e12144ad70ac6371eea5e11590b72feaeecc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049853
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66229}
This fixes a bug in lazy deopts caused by calls to the callback function
in Array.prototype.reduce and reduceRight.
The deopt continuation expects the *next* iteration's index value but
we actually passed the current iteration's value.
The user-visible effect of this bug was that sometimes, an unexpected
additional call to the callback function would occur.
It was introduced by https://crrev.com/c/1934329.
Bug: v8:9972,chromium:1049982
Change-Id: Icfd2ef076209e20602f54d4662220e1d4c5d07ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049850
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66226}
The Object::SetElement and JSObject::GetElement were
the GC suspects.
Fixed: v8:9995
Change-Id: Ia1f794188f08f0e2543a88eb4dc7a8b06dcb3deb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050391
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66223}
Adds support for off-thread allocation to Script allocation and
line-end calculation.
This includes adding support for keeping/merging a script list on
the OffThreadIsolate, and adding syntactical support for logging
(in the future this could do actual logging).
Bug: chromium:1011762
Change-Id: Id90f2ad7458e90e06f6926f1fce7ef7a1ef50b3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046884
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66213}
Deprecate the following explicit FinalizationGroup APIs in favor of
automatic handling of FinalizationGroup cleanup callbacks:
- v8::Isolate::SetHostCleanupFinalizationGroupCallback
- v8::FinaliationGroup::Cleanup
If no HostCleanupFinalizationGroupCallback is set, then
FinalizationGroup cleanup callbacks are automatically scheduled by V8
itself as non-nestable foreground tasks.
When a Context being disposed, all FinalizationGroups that are
associated with it are removed from the dirty list, cancelling
scheduled cleanup.
This is a reland of 31d8ff7ac5
Bug: v8:8179, v8:10190
Change-Id: I704ecf48aeebac1dc2c05ea1c052f6a2560ae332
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045723
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66208}
FunctionEntry StackChecks is one of the two cases where we generate a
StackCheck bytecode. In these cases, we do stack check against the js
limit (not to be confused with the real js limit). Their purpose is to
be able to interrupt the running code.
We can omit the FunctionEntry StackCheck by embedding its code into
the InterpreterEntryTrampoline builtin. We save one bytecode per
interpreted function.
This change has rippling effects for optimized code, as well as the
deoptimizer.
Bug: v8:10149, v8:9977, v8:9960
Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66206}
Introduce separate counters for young and old array buffer bytes. They
are used to keep the counter stable during sweeping when the array
buffer lists are moved to the concurrent thread for sweeping.
Bug: v8:10064
Change-Id: I0f11a634341873b4d21759c284c55beb26fe30a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045511
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66204}
This makes creating whitelisted runtime functions more permissive on
fuzzers (when --allow-natives-for-fuzzing is passed).
- Runtime functions with too few arguments are replaced with undefined.
- Superfluous arguments are ignored.
This reduces syntax-error rate on fuzzers. Also prevents
dcheck errors when fuzzing debug builds and fuzzers use too many
arguments for runtime functions.
Bug: chromium:1044942
Change-Id: I23b45398421c50bc82d1e8bfdf019f565253db96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039352
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66202}
Update external memory counters when using ArrayBufferExtensions. In
case the array buffers are swept concurrently, the counters are updated
at the beginning of the next minor/full GC. A subsequent GC is going
to update counters faster.
ArrayBufferExtension now stores the accounting_length such that
the sweeper always knows how much memory to deduct from the external
memory on destruction.
ArrayBufferList now also tracks the size of all ArrayBuffers in it.
Bug: v8:10064
Change-Id: I50a8b1180aa837b6932f834df1610255bd2bd9fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041441
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66195}
This reverts commit 31d8ff7ac5.
Reason for revert: https://crbug.com/v8/10190
Original change's description:
> [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8
>
> Deprecate the following explicit FinalizationGroup APIs in favor of
> automatic handling of FinalizationGroup cleanup callbacks:
> - v8::Isolate::SetHostCleanupFinalizationGroupCallback
> - v8::FinaliationGroup::Cleanup
>
> If no HostCleanupFinalizationGroupCallback is set, then
> FinalizationGroup cleanup callbacks are automatically scheduled by V8
> itself as non-nestable foreground tasks.
>
> When a Context being disposed, all FinalizationGroups that are
> associated with it are removed from the dirty list, cancelling
> scheduled cleanup.
>
> Bug: v8:8179
> Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66184}
TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8179
Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66190}
If both isolates run this test, they are kind of racing on the
{tier_down_} flag, hence you get unexpected results.
Bug: v8:10189, v8:10099
Change-Id: I8657c32c024898442d5c916cf15077c846276b1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044544
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66188}
Deprecate the following explicit FinalizationGroup APIs in favor of
automatic handling of FinalizationGroup cleanup callbacks:
- v8::Isolate::SetHostCleanupFinalizationGroupCallback
- v8::FinaliationGroup::Cleanup
If no HostCleanupFinalizationGroupCallback is set, then
FinalizationGroup cleanup callbacks are automatically scheduled by V8
itself as non-nestable foreground tasks.
When a Context being disposed, all FinalizationGroups that are
associated with it are removed from the dirty list, cancelling
scheduled cleanup.
Bug: v8:8179
Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66184}
We lower each op into num_lanes loads, and connecting up the effects in
a chain.
s64x2 is not implemented since we lowering for 64x2 generally doesn't
work anyway.
Load extends are a bit more complicated, so we'll do that in a separate
change.
Bug: v8:9886
Change-Id: I80096827bf8e8e0db1ef0ad1b76759ed1797ca5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031893
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66183}
This change moves the definition of the bits stored in DebugInfo::flags
to Torque, and updates the only Torque usage of that field to use more
natural syntax. This is intended as an example of common patterns found
in various other classes. Several supporting changes are required:
1. Add a new type representing a bitfield struct stored within a Smi. It
is currently called SmiTagged, but I'm open to suggestions.
2. Add an enum-style output for Torque bitfield structs whose bitfields
occupy only one bit each.
3. Add a new case to MachineOperatorReducer that makes the generated
code for IncBlockCounter match with what was generated before this
change.
4. Add support for reporting these bitfields in the postmortem debugging
API. The format matches existing bitfields but with an offset value
that includes the SMI shift size.
Bug: v8:7793
Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66182}
These were not added in https://crrev.com/c/2026067 when we added
similar tests for other lane sizes, since x64 had a completely different
path for i8x16. But this tests are useful anyway for other archs, so add
them in.
Bug: v8:10115
Change-Id: I77ecca0cd9f4021c94f1538aa5635b5d54983207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041708
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66178}
GlobalSize will be used as a hint to schedule scavenger work in
https://chromium-review.googlesource.com/c/v8/v8/+/2036661
This is implemented as an atomic variable that's updated when adding/removing
segments.
Bug: chromium:1012816
Change-Id: I8f6c3f10612f8febda9bfe640d91e235aa3c2f12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043273
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66175}
Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB
if the physical memory size is greater or equal to 16GB on 64-bit
platforms.
This CL also adds tests for configuring heap limits from the physical
memory size.
Bug: chromium:1045034
Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66174}
We used to optimize functions that are expected to executed only
once by not allocating feedback slots for some of the bytecodes. This
would help in reducing the memory and avoiding initializing feedback
that would be never used. With lazy feedback allocation, we don't
allocate feedback vectors for most of such functions anyway.
The generated bytecode for oneshot optimized functions is different and
if we don't properly track this information we might end up generating
different bytecode for the same function. This could causes problems
when there is a mismatch between the feedback slots used by the new
bytecode and the old bytecode. Since we potentially get most of the
benefits of this optimization with lazy feedback vector allocation
we can simplify the code by disabling this optimization.
Bug: chromium:1045824
Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66172}
Allow caching the result of allocating AstConsStrings, to allow
sharing of inferred names between functions.
This is a partial revert of https://crrev.com/c/2020953, with
the observation that *some* AstConsStrings are always flattened,
while others are only ever used as ConsStrings, so we want to
allow the allocation to be lazy while still caching the result.
As a drive-by, cleanup the old AstConsString linked list fields.
Bug: chromium:1011762
Bug: chromium:1048082
Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66168}
This is a reland of 410ca4c50e
Skip new test for unsupported liftoff architecture.
Previously, if there is some unsupported liftoff functions, it fall
through Turbofan but recompilation didn't catch and count it. This CL
fixes it by using requested_tier on finished units.
Avoid to tier down asm.js.
Introduce reached recompilation tier to monitor recompilation progress.
Original change's description:
> [wasm] Tierdown wasm module upon "Debugger.enable"
>
> Put a logic in Wasm Engine to tier down all existing modules per isolate
> when debugger is enabled. This CL does not handle new module added after
> debugger is enabled yet.
>
> Bug: v8:9654
> Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66017}
TBR=szuend@chromium.org,bmeurer@chromium.org
Bug: v8:9654
Change-Id: I6014ae52d1e04726e64ee9267c5ce559090414d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031744
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66164}
With "Value::parseBinary" now being revamped by https://crrev.com/c/2020518
and making use of "cbor::ParseCBOR", the extra endianness check
is not needed anymore as "ParseCBOR" already switches
the byte order in this line:
crdtp/cbor.cc
void ParseUTF16String(CBORTokenizer* tokenizer, ParserHandler* out) {
....
for (size_t ii = 0; ii < rep.size(); ii += 2)
value.push_back((rep[ii + 1] << 8) | rep[ii]);
...
"String16EndianTest" does not go through the newly added pipeline
and "ParseUTF16String" is never used which makes the test redundant.
Change-Id: I6ad59fef7036c70d475b492407fd394977ca98f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038716
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66160}
A pointer-compressed heap has the same heap limit heuristics as a 32-bit
heap. Specifically, the heap limit is restricted to 1GB due to scarce
virtual addresses space on 32-bit platforms. That limitation does not
apply for pointer-compressed heaps which can use 4GB.
This CL changes the heap limit computation to use system the pointer
size instead of the tagged pointer size. Note that the young generation
limit continues to use the tagged pointer size.
Bug: chromium:1045034
Change-Id: I9d5bb818c32a82322476e9c97feee331400ebe0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042102
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66159}
Add off-thread support for literals, including object/array boilerplates.
Notably, this includes adding FixedArray and HeapNumber support to
OffThreadFactory.
As a drive-by, OffThreadHandle is redefined to store an Address rather
than an Object, similar to Handle, so that it still works with forward
definitions of types.
Bug: chromium:1011762
Change-Id: I7c8452f450d8c57fe683a9e44532ce5647c84a11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036084
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66156}
The source position is set to the function call (console.log) not the
spread (..x), in the bytecode generator, as the spread operation is
done as part of the CallWithSpread bytecode.
The CallPrinter stops at the function call and doesn't look at the
arguments as well (in CallPrinter::VisitCall) to see if the error is
from an incorrect spread operation.
With this patch, we pass some state to the CallPrinter in the
CallWithSpread error case and check that in CallPrinter::VisitCall
before returning.
For the given source string:
```
x = undefined;
console.log(1, ...x);
```
Previously, the error was -
```
test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
console.log(1, ...x);
^
TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
at test.js:2:9
```
Now, the error is -
```
_test.js:2: TypeError: x is not iterable (cannot read property undefined)
console.log(1, ...x);
^
TypeError: x is not iterable (cannot read property undefined)
at _test.js:2:9
```
Bug: v8:10038
Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66131}
If new Liftoff code is generated but we already have either Liftoff or
TurboFan code, we still want to install and use the new Liftoff code if
we are in debugging.
This logic can probably be simplified again when the "tier down to
liftoff on Debugger.enable" logic is fully implemented. I left a TODO to
revisit the logic later.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66129}
These instructions were probably leftover from an earlier cleanup. We
can move them into respective macro lists, then delete away the
redundant declarations, definitions, disasm, and tests.
We were missing disasm tests for SSE2_INSTRUCTION_LIST_SD, so add that
in.
Change-Id: I8f27beaf57e7a338097690073910a0863f00b26a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036833
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66123}
The instruction selector assumed for Word32AtomicPairCompareExchange
nodes that if there exists a Projection(1) user, then there also exists
a Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
With this CL we allocate the right registers for the existing
projections, and allocate the other needed registers as temp registers.
R=gdeepti@chromium.org
Bug: v8:10140
Change-Id: Id50768c3cb712db5e0eb3b9dcd0a8a479e20953a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030731
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66122}
This relands commit 5cfe053e45.
Original change's description:
> [wasm-simd][liftoff] Add S128 case for stack movements
>
> The two cases we are fixing here are Construct and
> LoadCallerFrameSlot, which are closely related.
>
> Construct is called during PrepareCall, where we build up
> LiftoffStackSlots when we need to move an arg from caller's stack frame
> into callee's stack frame. LoadCallerFrameSlot is the parallel to
> this, called in ProcessParameter during decoding of the callee's
> function body.
>
> In most cases, Construct needs a new case to handle kWasmS128, and calls
> the relevant assembler to push a s128 onto the stack.
>
> ARM64 requires 16-byte alignment of sp, so we need to Claim the right
> number of kXRegSize slots first, which requires
> us traversing the list of slots to figure out how many s128 values there
> are. This is a straightforward way to fix this, if efficiency is a
> problem, we can change LiftOffStackSlots::Add to sum up the slot sizes.
>
> On IA32, pushing s128 values will require 4 calls to push. Instead, we
> use a sub and two movdqu, which will generate less code in most cases.
>
> On x64, there is no 128-bit push, so we call push twice.
>
> Bug: v8:9909
> Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65956}
Bug: v8:9909
Change-Id: Icdaead289abe13faf75bb9e049929f7fd7c59a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036760
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66119}
The debug side table is indexed by pc offset. Offsets change if
breakpoints are added or removed, hence we cannot reuse the debug side
table when compiling another version of the function (with a different
set of breakpoints). Thus store the debug side table per code object
instead of per function.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ifd77dd8f43c9b80bc4715ffe5ca8f0adca2aaf42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030922
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66110}
This is mostly used for regression tests which don't need that function.
If we want to wrap it for inclusion in an existing test file, we can
easily add a function around it, and name it properly.
R=ahaas@chromium.org
Bug: v8:10177
Change-Id: I2aedcdfad09fe1fe07af9f0caa2b8bd45da902f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036077
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66102}
