Commit Graph

61221 Commits

Author SHA1 Message Date
Leszek Swirski
5089344d45 [offthread] Fix double Compile compile
The interpreter's finalization was accidentally double-counting compile
finalizations, which manifested as a Compile count increase. As a side
effect, this would also miscount off-thread finalizations as main-thread
finalizations -- not a problem yet, but would be one in the future.

Bug: chromium:1011762
Bug: chromium:1060927
Change-Id: I37232bbd46c8cba80c0b413638f43d83d5313e70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098727
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66679}
2020-03-12 09:31:52 +00:00
Leszek Swirski
897786457f [parser] Remove unnecessary ParseInfo from Scope methods
Some Scope methods were unnecessarily taking a ParseInfo, or using only
a single field from it. We can avoid passing around ParseInfo in these
cases, which will make splitting/removing it easier in the future.

Bug: v8:10314
Change-Id: I5c60783d27581c4f7d8c709314bbfc72ac5bd0f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096630
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66678}
2020-03-12 08:52:41 +00:00
Zhao Jiazhong
622b1dc293 [mips][wasm-simd][liftoff] Implement add for f64x2, i64x2, i8x16
Port 485e66ba8e
https://crrev.com/c/2094198

Change-Id: I4e3ce2a70f2ccf4e95b0fa69834522d988e00f9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097895
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66677}
2020-03-12 08:12:11 +00:00
Iain Ireland
a2b17a7230 [regexp] Upstream small changes
This is a grab-bag of small compatibility fixes to make it easier to
import irregexp into SpiderMonkey. For changes where the commit
message was longer than the change itself, it didn't seem worth
opening a separate review.

[regexp] Use uc16 in FilterOneByte

SpiderMonkey uses char16_t instead of uint16_t for its two-byte
strings. (This matches ICU. It looks like V8 considered making the
same change, but decided against it: see
https://bugs.chromium.org/p/v8/issues/detail?id=6487.) Fortunately,
irregexp is careful about only using uc16, so SpiderMonkey can just
define uc16 = char16_t and *almost* everything works out. This patch
fixes the single place in irregexp where that is not true.

[regexp] Remove unreachable return

The return statement at the end of
RegExpParser::ParseClassCharacterEscape is unreachable, because every
branch of the switch returns. This triggered static analysis errors in
SpiderMonkey.

[regexp] Remove trivial assertion

The assertion in BytecodeSequenceNode::ArgumentMapping cannot fail,
because size_t is an unsigned type. This triggered static analysis
warnings in SpiderMonkey.

[regexp] Make RegExpStack constructor public

In V8, the RegExpStack's private constructor is called from Isolate,
which is a friend class. In SpiderMonkey, we use a wrapper around new
to control where memory is allocated, so we need the RegExpStack
constructor to be visible outside of Isolate.

[regexp] Refactor Isolate::IncreaseTotalRegexpCodeGenerated

The call-site of Isolate::IncreaseTotalRegexpCodeGenerated is the only
place inside irregexp where HeapObject::Size is called. SpiderMonkey's
heap-allocated objects live in arenas, and don't have a standardized
way of finding the size. In this particular case it would be safe to
hardcode a size of 0, but leaving HeapObject::Size undefined will
ensure that SpiderMonkey doesn't silently do the wrong thing if
somebody in V8 adds a new, more meaningful call to HeapObject::Size.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I5b81e1a261fec8c85a63f71f34cd12d68f638334
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090191
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66676}
2020-03-12 07:07:12 +00:00
Andreas Haas
e35b048c49 [wasm][liftoff] Implement memory.copy
R=clemensb@chromium.org

Bug: v8:10281
Change-Id: Icf7f8138d0acc172da6ff31935e50de3e4c79e10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096622
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66675}
2020-03-12 07:00:41 +00:00
Iain Ireland
5b44c16915 [regexp] Use ZoneVector in parser and compiler
For a variety of reasons related to OOM handling and custom
allocators, SpiderMonkey wants to be able to see all memory
allocations. To enforce this, we have a static analysis that verifies
that we don't link in malloc/new/etc in unexpected places. One
consequence of this is that we can't use STL containers without a
custom allocator, because they call operator new internally.

This is mostly not an issue in irregexp, which makes heavy use of zone
allocation. The main exceptions are a handful of uses of std::vector
in regexp-compiler.* and regexp-parser.*. If these vectors are
converted to ZoneVectors, then our static analysis is satisfied.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I8b14a2eb54d3b20959e3fbe878f77effae124a2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091402
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66674}
2020-03-12 06:58:52 +00:00
Iain Ireland
9b5141ca84 [regexp] Cache min/max-match for RegExpCapture/Group
Unlike the other RegExpTree types, RegExpCapture and RegExpGroup don't
cache their min/maxMatch value. Instead, they compute it by recursing
on the min/maxMatch of the body node. In pathological cases, with
sufficiently small stacks, this can cause stack overflow. (In
SpiderMonkey's case, it was a worker on 32-bit x86.)

It's easy enough to just precompute the value when the body is set.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I4ba3d301d9a4a3f3c0cb94966148b747a4092d26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090192
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66673}
2020-03-12 06:57:31 +00:00
Iain Ireland
73da478c82 [regexp] Remove function pointer in TextEmitPass
TextEmitPass uses a function pointer to determine which pass to
call. This function pointer is only assigned inside TextEmitPass, and
can easily be eliminated by moving the calls to each possible target
inside the switch statement that assigns the function pointer.

I made this change because SpiderMonkey uses a static analysis pass to
verify that everything is rooted properly across calls that might GC,
and that analysis is conservative when calling function pointers. We
can white-list function pointers that are known to be safe, but the
code being called through this function pointer is complex enough
(and the function pointer is unnecessary enough) that it seemed best
to just remove the function pointer entirely.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I5fbb0df290a2288c4d3db6d43a563385337162ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091398
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66672}
2020-03-12 06:54:12 +00:00
v8-ci-autoroll-builder
025319bfd9 Update V8 DEPS.
Rolling v8/build: 3e21004..8a766f0

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a8e510a..786ed18

Rolling v8/third_party/depot_tools: 552ddbf..1ee78cd

Rolling v8/tools/clang: 0a95832..ca7cd9b

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: I48f6192edf8a261dce59069cdf3aec227fe3875a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099004
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66671}
2020-03-12 03:56:52 +00:00
Andreas Haas
e08e9d8992 Reland "[wasm] Do memory.init bounds check in C++ code"
The return value of {memory_init_wrapper} was defined as {bool} in
the original CL. When compiled with clang, the full return register is
written when {true} or {false} is returned. With msvc, however, the
return value is written as a single byte, without zero-extension. In
generated code, the full return register is used and therefore stale
bytes in the return register caused problems.

With this CL the return value is changed to {uint32_t}. This enforces
zero-extension of the return value and thereby fixes the issue.

R=clemensb@chromium.org

Bug: v8:10281
Change-Id: I1446e51d88a35def56bd39a8336baa81543497bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096627
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66670}
2020-03-11 22:05:49 +00:00
Z Nguyen-Huu
e7de8c3a2d [wasm] Remove $ prefix in naming variable, global
Bug: v8:10242
Change-Id: Ie6583fe819de94185826dfd6a1b11870800847c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098216
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66669}
2020-03-11 20:50:59 +00:00
Santiago Aboy Solanes
b8d8ab4132 [interpreter] Move IterationBody StackChecks to end of loops
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}
2020-03-11 18:12:09 +00:00
Z Nguyen-Huu
1dcaea823f [wasm] Adopt compatible naming for functions
We want to be consistent with wasdk/wasmparser.

Unnamed function's name would be func#

Doc: https://docs.google.com/document/d/1XoXWONLBgZWQ9dhtoMpQPvD0fnnWA50OorsuSXfME3g
Bug: v8:10242
Change-Id: I12222eef38a57242e9f606007d0ffa76b8e2a4af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084052
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66667}
2020-03-11 16:53:09 +00:00
Andreas Haas
126f1ee14f Reland "[wasm] Do memory.copy bounds check in C++ code"
The return value of {memory_copy_wrapper} was defined as {bool} in
the original CL. When compiled with clang, the full return register is
written when {true} or {false} is returned. With msvc, however, the
return value is written as a single byte, without zero-extension. In
generated code, the full return register is used and therefore stale
bytes in the return register caused problems.

With this CL the return value is changed to {uint32_t}. This enforces
zero-extension of the return value and thereby fixes the issue.

R=clemensb@chromium.org

Bug: v8:10281
Change-Id: I628d01cfd7193fa960a7ccdf0d9fd896f510cd3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096626
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66666}
2020-03-11 16:39:19 +00:00
Milad Farazmand
8d28f299fd s390: [wasm-simd] separate lanes for simd AllTrue opcodes
Change-Id: I88c43793b82256e9f37ffd54468fd0374fedd164
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097025
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66665}
2020-03-11 14:53:49 +00:00
Jakob Kummerow
fb3da4ec8d [gm.py] Specify python2 for now
Because run-tests.py still requires it.

No-try: true
Change-Id: Ief1f3d7a93ba4c36232420ee9ab0a4ff3ea6739b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096628
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66664}
2020-03-11 14:42:59 +00:00
Dominik Inführ
82aaf737df [heap] Introduce LocalHeap class
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}
2020-03-11 14:40:29 +00:00
Milad Farazmand
384b94170a PPC/s390: [wasm-simd] [liftoff] Implement add for f64x2, i64x2, i8x16 on X64 and IA32
Port 485e66ba8e

R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I2e1b79a995661243ff05b3d13e310f6315de0c97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097450
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66662}
2020-03-11 13:38:29 +00:00
Matheus Marchini
931bdbd76f [torque] fix build on VS2017
Node.js build fails on VS2017 without these headers, see the downstream
issue (https://github.com/nodejs/node-v8/issues/128).

Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
Co-authored-by: gengjiawen <technicalcute@gmail.com>
Change-Id: I771eab435dce5cf548581f3acd78681180c77692
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093951
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66661}
2020-03-11 13:02:49 +00:00
Milad Farazmand
c8bfe9a8a3 s390: [build] disable fp multiply and accumulate instructions
Some wasm interpreter tests are failing since instructions generated
by gcc such as *multiply and and* create intermediate results bigger
than 8 bytes which doesn't match other architectures, hence the
resulting output differs.

Change-Id: I68cc58d01699bfe93051da693c4b7e819ffcc6eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095613
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66660}
2020-03-11 12:42:09 +00:00
Georg Neis
2089ff6835 [turbofan] Refine typing of equality
Generalize the HeapConstant case to a Singleton case.

Change-Id: Ief8c325a4326e02c8c361f3b41fc40ca398167ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096619
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66659}
2020-03-11 12:37:49 +00:00
Clemens Backes
b8eeb071c3 Revert "[wasm] Do memory.copy bounds check in C++ code"
This reverts commit c475e70460.

Reason for revert: Fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805

Original change's description:
> [wasm] Do memory.copy bounds check in C++ code
> 
> In the existing implementation we first did a bounds check in generated
> code, and then called a simple C++ function to do the actual copying.
> With this CL now we pass the WasmInstanceObject to the C++ function in
> addition to the memory.copy parameters. Thereby we can do the bounds
> check in C++, which is much easier, less error prone, and which also
> speeds up code generation and reduces code size. Performance should not
> be worse, because we were already doing the call to C++ anyways.
> 
> R=​clemensb@chromium.org
> 
> Bug: v8:10281
> Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66655}

TBR=ahaas@chromium.org,clemensb@chromium.org

Change-Id: Ic2491f635a292e004f6c95498a045ba102138dc5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10281
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096623
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66658}
2020-03-11 11:54:44 +00:00
Clemens Backes
c5cecf8d3d Revert "[wasm] Do memory.init bounds check in C++ code"
This reverts commit c7a26b1316.

Reason for revert: Need to revert previous CL because it fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805

Original change's description:
> [wasm] Do memory.init bounds check in C++ code
> 
> In the existing implementation we first did a bounds check in generated
> code, and then called a simple C++ function to do the actual copying.
> With this CL now we pass the WasmInstanceObject to the C++ function in
> addition to the memory.init parameters. Thereby we can do the bounds
> check in C++, which is much easier, less error prone, and which also
> speeds up code generation and reduces code size. Performance should not
> be worse, because we were already doing the call to C++ anyways.
> 
> R=​clemensb@chromium.org
> 
> Bug: v8:10281
> Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66656}

TBR=ahaas@chromium.org,clemensb@chromium.org

Change-Id: I1064113e7f1c445d04652a973c994317fd3e739a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10281
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096624
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66657}
2020-03-11 11:53:38 +00:00
Andreas Haas
c7a26b1316 [wasm] Do memory.init bounds check in C++ code
In the existing implementation we first did a bounds check in generated
code, and then called a simple C++ function to do the actual copying.
With this CL now we pass the WasmInstanceObject to the C++ function in
addition to the memory.init parameters. Thereby we can do the bounds
check in C++, which is much easier, less error prone, and which also
speeds up code generation and reduces code size. Performance should not
be worse, because we were already doing the call to C++ anyways.

R=clemensb@chromium.org

Bug: v8:10281
Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66656}
2020-03-11 10:57:39 +00:00
Andreas Haas
c475e70460 [wasm] Do memory.copy bounds check in C++ code
In the existing implementation we first did a bounds check in generated
code, and then called a simple C++ function to do the actual copying.
With this CL now we pass the WasmInstanceObject to the C++ function in
addition to the memory.copy parameters. Thereby we can do the bounds
check in C++, which is much easier, less error prone, and which also
speeds up code generation and reduces code size. Performance should not
be worse, because we were already doing the call to C++ anyways.

R=clemensb@chromium.org

Bug: v8:10281
Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66655}
2020-03-11 10:53:49 +00:00
v8-ci-autoroll-builder
166bd9e88a Update V8 DEPS.
Rolling v8/build: 9b4e026..3e21004

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/abdb603..a8e510a

Rolling v8/third_party/depot_tools: a12175c..552ddbf

Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1

Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1

Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1

Rolling v8/tools/swarming_client: 0ac2847..cc95827

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: I59b2eb12c51114c798fbbc9008952952736ebe7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097639
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66654}
2020-03-11 04:00:28 +00:00
Kong, Fanchen
485e66ba8e [wasm-simd] [liftoff] Implement add for f64x2, i64x2, i8x16 on X64 and IA32
Bug: v8:9909
Change-Id: I6766c1d0f347f8e0c8dea588e5984eb48ad18d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094198
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jing Bao <jing.bao@intel.com>
Cr-Commit-Position: refs/heads/master@{#66653}
2020-03-11 01:32:27 +00:00
Ng Zhi An
f63189d60f [wasm-simd][liftoff][arm][arm64] I32x4 I16x8 F32x4 add
Bug: v8:9909
Change-Id: Ic309d394620ec17791bac2902116e15058b28a68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091634
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66652}
2020-03-10 17:15:18 +00:00
Dominik Inführ
8d08318e1a [heap] Report allocated size of global handles
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}
2020-03-10 16:46:48 +00:00
Richard Townsend
2cdbb99b3e [arm64][msvc] Fix the embedded snapshot writer for Windows on Arm, MSVC
Suffered from a confusion of masm/marmasm syntax for the x64 host and
arm64 target (could only generate one syntax or ther other). Fixed by
moving the compile-time flag to a runtime one.

Bug: v8:10012

Change-Id: I34746a495b1881c1d0465995930979bb768b07e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962854
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66650}
2020-03-10 16:00:48 +00:00
Leszek Swirski
b471280268 [parser] Set script id on ParseInfo creation
Rather than having an optional script id during ParseInfo creation (which
is either selected lazily on script creation, or eagerly if based on an
existing Script), always eagerly get either the desired script id (either
from the Script or Isolate::GetNextScriptId()).

This has the side-effect that we will currently no longer need to get the
script id on background threads, but I'm not reverting the thread-safety
of Isolate::GetNextScriptId in case it's needed again in the future.

Bug: v8:10314
Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66649}
2020-03-10 15:41:08 +00:00
Leszek Swirski
e68b59415e [parser] Remove ParseInfo flag setting after script creation
Previously, ParseInfo would create a script (with CreateScript) based on
its flags, and then set its own flags based on that created script. This
created a weird circular dependency for some of those flags, and
sometimes we would have valid flags before script creation (main thread
compile), while other times not (streaming compile).

Now we set the ParseInfo flags manually and uniformly before script
creation, and check that they match the created script after it has been
created.

Bug: v8:10314
Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66648}
2020-03-10 15:31:09 +00:00
Victor Gomes
a05ee6cb0d [compiler] Add CallJSStub
The arguments order in a JS stack is now controlled by
V8_REVERSE_JSARGS macro.
This CL creates two stubs that allow the order of the arguments
to be reversed without changing CallStub.

Bug: v8:10201
Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66647}
2020-03-10 14:10:58 +00:00
Dan Elphick
1c922f0f91 [compiler] Add runtime call stats for builtin generation
Useful for profiling why mksnapshot is so slow in conjunction with
--runtime-call-stats.

Change-Id: Ib193d292352e0019b93c8edccb38a904aadbf553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089932
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66646}
2020-03-10 12:59:18 +00:00
Janusz Majnert
5a04c5cea2 Make torque emit structs in classes in order
Torque compiler emits a C++ class definition header
class-definitions-tq.h. Unfortunately it does so in a manner that
introduces randomness into the ordering of some structs. This means that
every full build of V8 may yield a different header.
Since this header is included in a lot of files in V8, it causes a lot
of ccache misses (over a 1000).

This commit makes sure that the structs are emitted in lexical order.

Bug: v8:10310
Change-Id: Ie39066d36e41583ff990bc639f7f241462351585
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093500
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66645}
2020-03-10 12:52:38 +00:00
Milad Farazmand
9d3cca1cd3 s390: [arm] Add missing RELATIVE_CODE_TARGET iteration
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}
2020-03-10 12:04:08 +00:00
Leszek Swirski
4f3b0990ef [parser] Move ParseInfo wrapped argument setup
Change wrapped argument set-up to be closer to where it's needed: setting
up a top-level SFI, or initializing a ParseInfo from a top-level SFI.

This is a generally cleaner use of the interface, avoids splitting the
setting of the funciton syntax kind and wrapped arguments (including
checking script.is_wrapped() in two places for the same behaviour), plus
it avoids unnecessarily creating wrapped_argument handles for functions
inside a wrapped script.

As a drive-by, rename ParseInfo::SetFlagsFromScript to a clearer

ParseInfo::SetFlagsForFunctionInScript, to differentiate between flags
from a script for top-level vs. non-top-level.

Bug: v8:10314
Change-Id: Ibdaad957558c13a1528dcc3da1ba8f262f357e48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093509
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66643}
2020-03-10 11:24:18 +00:00
Jakob Kummerow
085c804f79 [gm.py] Migrate to Python 3
The code was almost compatible, only one small issue had snuck in.

No-try: true
Change-Id: I52225fb2092bf16a5fffbde957cd1dfe4f2c4fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093492
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66642}
2020-03-10 11:17:08 +00:00
Iain Ireland
3fab9d05cf [regexp] Fix and unify non-unicode case-folding algorithms
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}
2020-03-10 11:09:28 +00:00
Daniel Bevenius
61d496a656 [stack-guard] Fix typo in stack limit comment
Change-Id: If9ef15e1ecbb75b7542b8033f68e63ba1a08cae1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091470
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66640}
2020-03-10 06:24:28 +00:00
v8-ci-autoroll-builder
57cc1d36dc Update V8 DEPS.
Rolling v8/build: 1739acf..9b4e026

Rolling v8/buildtools: fa6ae42..1a8a3a7

Rolling v8/buildtools/linux64: git_revision:4166e9fbc1fa5ceab69b69710a0f8b430c50127b..git_revision:fd3d768bcfd44a8d9639fe278581bd9851d0ce3a

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c5f5b9e..abdb603

Rolling v8/third_party/depot_tools: ffd0295..a12175c

Rolling v8/tools/clang: 0f734f7..0a95832

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: Ib266db1413cabf622559762833896b304d6deeb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095247
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66639}
2020-03-10 03:44:28 +00:00
Ng Zhi An
d86f8ea50a Fix checking of prefixed memory ops in fuzzer
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}
2020-03-09 23:13:37 +00:00
Shu-yu Guo
a99a9b2731 Fix ToInteger_Inline to call builtin instead of ToIntegerImpl
Previous commit incorrectly inlined ToIntegerImpl into ToInteger_Inline,
causing code bloat.

Bug: chromium:1059364
Change-Id: I7bc369255a29a7ea567fafc775835c37584905b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2092843
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66637}
2020-03-09 20:28:08 +00:00
Joyee Cheung
0ea5b5248d [class] implement inspector support for static private methods
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}
2020-03-09 20:19:17 +00:00
Frank Tang
77e6f2c42a Correctly remove fractionalSecond tests
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}
2020-03-09 20:02:17 +00:00
Z Nguyen-Huu
fe74c4f7c7 [wasm] Tierup wasm module on debugger.disable
Bug: v8:10290
Change-Id: I35670fef49a89cd075fb654daec4b55440266673
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2088231
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66634}
2020-03-09 17:39:37 +00:00
Seth Brenith
8b1a5681de [tools] Fix v8windbg behavior on Map's bit_field2
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}
2020-03-09 17:36:27 +00:00
Ng Zhi An
9b666ea6ab [wasm-simd][liftoff] Skip loads of high fp reg in simd pairs
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}
2020-03-09 16:26:57 +00:00
Andreas Haas
b8bfa85f11 [wasm] Extract StoreArgsInStackSlot function
There exists the pattern in wasm-compiler.cc of allocating a stack slot
and filling it with values. This CL introduces a helper function for
this pattern. Note that not all cases of this pattern can be changed to
use the helper function. In these cases either the size of the stack
slot is not statically known, or the stack slot is also used for return
values.

R=clemensb@chromium.org

Bug: v8:10155
Change-Id: I8497a22fed730424561fc32bc1cfa21643341643
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093495
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66631}
2020-03-09 16:06:57 +00:00
Clemens Backes
c8d8ff2a1c [wasm] Remove obsolete flags from inspector test
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.org
CC=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}
2020-03-09 15:12:27 +00:00