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}
