Bug: chromium:723802
Change-Id: I8f23d016a5aaf785fcd27cd139a196a148a37069
Reviewed-on: https://chromium-review.googlesource.com/508712
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45424}

[builtins] Enable %TypedArray%.prototype.{some,every,reduce,reduceRight,map} CSA builtins by default

R=danno@chromium.org

Change-Id: I3365642b2682c09d745b7bcc9f983179604e7c3a
Reviewed-on: https://chromium-review.googlesource.com/509549
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45423}

Currently only relies on private stacks of segments, i.e., doesn't steal
anything, yet.

Bug: chromium:651354
Change-Id: Icedad3e3169b61afe988a1ece10f73f3a973bdb2
Reviewed-on: https://chromium-review.googlesource.com/508351
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45422}

This adds reporting of linking failures (i.e. module instantiation)
similar to the existing reporting for validation failures. Note that
the messages in question are deterministic and can be tested.

R=clemensh@chromium.org

Change-Id: Ibecebefb86f1d878f626702c05fd0cb21189dc2a
Reviewed-on: https://chromium-review.googlesource.com/507488
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45421}

Revert of Add DEPS.chromium for recursive DEPS tracking. (patchset #1 id:1 of https://codereview.chromium.org/2880293002/ )

Reason for revert:
Going a different way with this, as Chromium don't want the additional files.

Original issue's description:
> Add DEPS.chromium for recursive DEPS tracking.
>
> DEPS.chromium allows the Chromium build system's DEPS to recurse into V8's own
> dependencies. Initially, this is populated with some tests files for the ARM64
> simulator.
>
> BUG=chromium:718439
>
> Review-Url: https://codereview.chromium.org/2880293002
> Cr-Commit-Position: refs/heads/master@{#45310}
> Committed: https://chromium.googlesource.com/v8/v8/+/f8a6c6c48e79ef4267d03c80aa768e8362341e4a

TBR=machenbach@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:718439

Review-Url: https://codereview.chromium.org/2891323002
Cr-Commit-Position: refs/heads/master@{#45420}

This simplifies the growing strategy used in {ZoneBuffer} and also tunes
the initial sizes used for various instances of these buffers. Note that
such a {ZoneBuffer} is used for entire modules and individual function
bodies.

R=clemensh@chromium.org

Change-Id: I99a0898589984e1830c681845fabb0ed5f8317ab
Reviewed-on: https://chromium-review.googlesource.com/508711
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45419}

We can avoid some runtime calls by implementing intrinsics.

BUG=

Review-Url: https://codereview.chromium.org/2889973002
Cr-Commit-Position: refs/heads/master@{#45418}

In a recent CL I moved the corpus of the wasm fuzzer and of the
wasm-asmjs fuzzer to a different directory
(wasm_corpus and wasm_asmjs_corpus) so that the corpus is not executed
on the try-bots. With this CL I remove the old corpus from the
.gitignore file.

In addition I removed the hooks for wasm_corpus and
wasm_asmjs_corpus from the V8 DEPS file, because in a V8 checkout
they are not used anyway.

I also added code to the test runner to delete all *.wasm files
from the directories test/fuzzer/wasm and test/fuzzer/wasm_asmjs.
This code should be removed in a week, but it will help my coworkers
to cleanup their V8 checkout.



R=bradnelson@chromium.org
CC=machenbach@chromium.org

Change-Id: I9fdf9d77b71b133f84f7e744763d65fdf127d624
Reviewed-on: https://chromium-review.googlesource.com/505614
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45417}

NOTRY=true
TBR=franzih@chromium.org

Bug: v8:6154
Change-Id: Ief1e1acb353ba1c857616c32607979aec462207a
Reviewed-on: https://chromium-review.googlesource.com/509488Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45416}

In crrev.com/2856103002 sentinel frequency values were introduced, using
NaN as the sentinel. However the comparison function was not *fully*
updated to support these - comparing two NaNs would give ambiguous
results. This caused test failures when building with VS 2017, probably
because of subtle changes in the arrangement of nodes in the tree.

This change uses the the node ID to break ties. An alternative would be
to use a non-NaN sentinel value.

R=bmeurer@chromium.org
BUG=chromium:722480

Review-Url: https://codereview.chromium.org/2894433004
Cr-Commit-Position: refs/heads/master@{#45415}

Introduce a flag --max-inlined-nodes-absolute that is used to limit the
number of nodes that we inline even in the presence of small function
inlining, so that TurboFan graphs don't grow arbitrary large.

BUG=chromium:724084,v8:6395,v8:6278,v8:6344,v8:6394
TBR=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2894523005
Cr-Commit-Position: refs/heads/master@{#45414}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ce01161..8da5cdf

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/d76621c..b1c6aa7

Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/fd2abab..c844075

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/162cac4..ba46613

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: I59daef22f238d257f577dc1617aa5401c952e708
Reviewed-on: https://chromium-review.googlesource.com/509229Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45413}

This refactoring makes it easier to write advanced tests and
gives full control over what's happening to the test code.
It also forces description for every test.

BUG=none

Review-Url: https://codereview.chromium.org/2891213002
Cr-Commit-Position: refs/heads/master@{#45412}

As per spec, (https://github.com/WebAssembly/design/pull/1068), we
don't have compile/instantiate overloads anymore, instead, we
have explicitly named members.

This change introduces the new APIs, implements instantiateStreaming
based on compileStreaming, and uses the existing embedder mechanism.
It does not yet remove the functionality from compile/instantiate -
we do that after we adopt the new APIs on the blink side.

Also, it temporarily handles exceptions on the v8 side, which is also
something we'll move to the blink side.

Bug: 
Change-Id: I77673b1c0d395dfcf13b2f25464fd5dfd99c8d82
Reviewed-on: https://chromium-review.googlesource.com/508852
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45411}

Port 73d21080

Original Commit Message:

    Now that the optimized code hangs off the feedback vector, it is possible
    to check whether a function has optimized code available every time it's
    called in the interpreter entry trampoline. If optimized code exists, the
    interpreter entry trampoline 'self-heals' the closure to point to the
    optimized code and links the closure into the optimized code list.

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6246
LOG=N

Review-Url: https://codereview.chromium.org/2897483002
Cr-Commit-Position: refs/heads/master@{#45410}

- moved all extensions to inspector_test.cc;
- properly supported multiple context groups and sessions;
- better isolation between components;
- better infrastructure in protocol-test.

BUG=chromium:590878

Review-Url: https://codereview.chromium.org/2890463004
Cr-Commit-Position: refs/heads/master@{#45409}

If the new Free function is not implemented, but we are freeing a Normal
allocation, as opposed to one with guard regions, we can fall back on the
existing Free function.

Because guard regions are not yet used in normal circumstances, this will let
embedders who have not implemented the improve ArrayBuffer::Allocator interface
to continue working.

Bug: 
Change-Id: I2e30b523ef7493ab288110b90d8f994bfcfbc9b7
Reviewed-on: https://chromium-review.googlesource.com/508897
Commit-Queue: Eric Holk <eholk@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45408}

WebAssembly needs to be able to allocate memory with guard regions, which
requires more functionality from the array buffer allocator. This change adds
functions for reserving memory regions and changing the memory protection.

This CL also includes some minor refactoring of the code to free array buffers.

Bug: chromium:720302
Change-Id: Iab9a266003043b0d36592a79668d1eea53952abf
Reviewed-on: https://chromium-review.googlesource.com/506377Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45407}

Split BytecodeGenerator::VisitSuspend into two pieces, one for
building the suspension code and one for resumption (these
are split into separate Build methods for convenience).
Each gets its own RegisterAllocationScope, which allows us to
reduce the register file size of the empty generator by 1.

For consistency, rename VisitGeneratorPrologue() to
BuildGeneratorPrologue() to match the names of the two
newly-created methods.

This relands the patch originally committed in
98927ea5, as the test failure
due to that change was a code flushing bug. Code flushing was
disabled in de4a4095.

R=rmcilroy@chromium.org

Bug: v8:6379
Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
Reviewed-on: https://chromium-review.googlesource.com/508814Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45406}

Varblock scopes can be treated as the "same scope" as their surrounding
function scope for the purposes of hole check elimination, as
source position comparison is sufficient to determine statically that
uses in the varblock scope are after initialization in the function scope.

This allows the elimination of hole checks of lexically-bound parameter
variables in functions with complex parameters, including rest parameters.

The pre-existing code compared DeclarationScopes for legacy reasons:
varblock scopes (and Scope::GetClosureScope()) did not exist at the
time this code was originally written.

R=neis@chromium.org

Bug: v8:6344, v8:6414
Change-Id: Ie787d58d1ea172e893788a9c716d3b6868980ab8
Reviewed-on: https://chromium-review.googlesource.com/508242
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45405}

This reverts commit ce538f70.

Reason for revert: breaks BOM handling (thus breaking Outlook web apps).

Original change's description:
> [parser] Refactor streaming scanner streams.
> 
> Unify, simplify logic, reduce UTF8 specific handling.
> 
> Intend of this is also to have stream views.
> Stream views can be used concurrently by multiple threads, but
> only one thread may fetch new data from the underlying source.
> This together with unified stream view creation is intended to be
> used for parse tasks.
> 
> BUG=v8:6093
> 
> Change-Id: Ied8e93090c506d4735080298f0fdaeed32043915
> Reviewed-on: https://chromium-review.googlesource.com/501789
> Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45336}

TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
BUG=v8:6093, chromium:724166

Change-Id: I022a23b8052d20d83a640c07b7864c622548bf90
Reviewed-on: https://chromium-review.googlesource.com/508888Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45404}

This patch adds HeapObject::set_map_after_allocation method that
initializes the map of the object without object layout checks.

All other map setters now check that transitions unsafe for
concurrent marking properly notify the GC.

BUG=chromium:694255

Review-Url: https://codereview.chromium.org/2885883004
Cr-Commit-Position: refs/heads/master@{#45403}

Port bfa319e5

Original Commit Message:

    We already had an optimization to turn Function.prototype.apply with
    arguments object, i.e.

      function foo() { return bar.apply(this, arguments); }

    into a special operator JSCallForwardVarargs, which avoids the
    allocation and deconstruction of the arguments object, but just passes
    along the incoming parameters. We can do the same for rest parameters
    and spread calls/constructs, i.e.

      class A extends B {
        constructor(...args) { super(...args); }
      }

    or

      function foo(...args) { return bar(1, 2, 3, ...args); }

    where we basically pass along the parameters (plus maybe additional
    statically known parameters).

    For this, we introduce a new JSConstructForwardVarargs operator and
    generalize the CallForwardVarargs builtins that are backing this.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6407,v8:6278,v8:6344
LOG=N

Review-Url: https://codereview.chromium.org/2887153004
Cr-Commit-Position: refs/heads/master@{#45402}

Revert of [csa] Add assertions to CSA (patchset #11 id:200001 of https://codereview.chromium.org/2847923003/ )

Reason for revert:
Seems to have made nosnap debug very slow and also leads to check failures:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13248

Original issue's description:
> [csa] Add assertions to CSA
>
> This adds a bunch of assertions to CSA, mostly about documenting and checking
> parameter types.
>
> Drive-by-change: Removed unused function.
>
> BUG=v8:6325
>
> Review-Url: https://codereview.chromium.org/2847923003
> Cr-Commit-Position: refs/heads/master@{#45398}
> Committed: https://chromium.googlesource.com/v8/v8/+/b14a981496ad1f841683479d2f9188dfa2d6b4bd

TBR=cbruni@chromium.org,ishell@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6325

Review-Url: https://codereview.chromium.org/2892023002
Cr-Commit-Position: refs/heads/master@{#45401}

BUG=chromium:716032

Review-Url: https://codereview.chromium.org/2890603007
Cr-Commit-Position: refs/heads/master@{#45400}

Generators were previously treated as "top level" for preparsing purposes,
since all their variables are context-allocated. But doing so isn't quite
correct: the allocation of the "arguments" variable for a generator
depends on whether it's referenced, and so an inner arrow function
which references "arguments" won't properly trigger allocation of
"arguments" since the reference will not be noticed in the preparser.

The same problem exists for "this" since commit 68f0a47b;
before that commit, all generators implicitly referenced their "this" argument
as part of the desugaring. With that implicit reference gone, "this"
falls into the same problem as arguments.

This patch restricts the special "top level" treatment to modules,
which have only a trivial "this" binding (it's always undefined), and no
arguments binding. Moreover, all code inside modules is strict, meaning
that unresolved references to "this" will also result in undefined.

R=marja@chromium.org

Bug: chromium:723132
Change-Id: I814d145fb8f3f1a65abb48e4e35595428d063051
Reviewed-on: https://chromium-review.googlesource.com/508055Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45399}

This adds a bunch of assertions to CSA, mostly about documenting and checking
parameter types.

Drive-by-change: Removed unused function.

BUG=v8:6325

Review-Url: https://codereview.chromium.org/2847923003
Cr-Commit-Position: refs/heads/master@{#45398}

Uses CheckSmi to force the switch argument to be a Smi, so that it can
be used as an input into a Switch node.

Change-Id: Ibec6beaeebc2168a3f80b86512c70a99d52f2575
Reviewed-on: https://chromium-review.googlesource.com/505621
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45397}

Add configs for:
https://chromium-review.googlesource.com/c/508349

NOTRY=true
TBR=ulan@chromium.org

Bug: chromium:723600
Change-Id: Ie0be3d34cc35a72c012c601d0bf8c8b707e69f32
Reviewed-on: https://chromium-review.googlesource.com/508628
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45396}

For additions like a+'' or ''+a where we have String feedback on the
JSAdd, we can drop the concatenation and just check that a is a valid
String already (via CheckString).

BUG=v8:6259
R=petermarshall@chromium.org

Review-Url: https://codereview.chromium.org/2894563002
Cr-Commit-Position: refs/heads/master@{#45395}

BUG=v8:6389,v8:6379,v8:6409

Change-Id: I24e0c8b6212f2cf2877d52f27eca0beb133afa1e
Reviewed-on: https://chromium-review.googlesource.com/508348Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45394}

For a single deferred commands, using a jump table is overkill, so
instead simply test the token against the single entry.

Bug: v8:4280
Bug: v8:6218
Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77
Reviewed-on: https://chromium-review.googlesource.com/506153
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45393}

BUG=

Review-Url: https://codereview.chromium.org/2892713002
Cr-Commit-Position: refs/heads/master@{#45392}

Restore original behavior in that strings are deduplicated in lower-case
conversion (i.e. if the string is already lower-case, the original
string is returned).

BUG=v8:6353,v8:6412

Review-Url: https://codereview.chromium.org/2891853004
Cr-Commit-Position: refs/heads/master@{#45391}

Change-Id: I4b19700b613f81601321a336cc758cfd7f826f3e
Reviewed-on: https://chromium-review.googlesource.com/504347Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45390}

R=clemensh@chromium.org

Change-Id: Ic1cc9bd5560a315128242dc58b29a76e359ca11f
Reviewed-on: https://chromium-review.googlesource.com/507212Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45389}

We already had an optimization to turn Function.prototype.apply with
arguments object, i.e.

  function foo() { return bar.apply(this, arguments); }

into a special operator JSCallForwardVarargs, which avoids the
allocation and deconstruction of the arguments object, but just passes
along the incoming parameters. We can do the same for rest parameters
and spread calls/constructs, i.e.

  class A extends B {
    constructor(...args) { super(...args); }
  }

or

  function foo(...args) { return bar(1, 2, 3, ...args); }

where we basically pass along the parameters (plus maybe additional
statically known parameters).

For this, we introduce a new JSConstructForwardVarargs operator and
generalize the CallForwardVarargs builtins that are backing this.

BUG=v8:6407,v8:6278,v8:6344
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2890023004
Cr-Commit-Position: refs/heads/master@{#45388}

We use Schedule::EnsureDeferredCodeSingleEntryPoint as a helper for 
hand-crafted builtin code, to ensure deferred code isn't entered from a
mix of deferred and non-deferred code (invariant required for hot/cold
allocation, or "splintering").

When we create a "merger" block, it may be the case that the original 
block had a few phi operands. Those need to be moved as well.

This bug was uncovered by both v8:6390, and, earlier, by v8:5998. We 
fixed the earlier one by authoring a the builtin to avoid the need for
EnsureDeferredCodeSingleEntryPoint. I proposed earlier an alternative 
where we'd replace the Ensure... method with a Verify, and throw early
when the builtin is assembled, however, we may want to maintain the 
slightly higher level DSL for authoring builtins, and perform such 
graph adjustments for the lower level constraints afterwards, hence 
this current CL.

Bug: v8:5998 v8:6390
Change-Id: Ia3143f7a66904fe480d8edb5b52bf915b8d185dc
Reviewed-on: https://chromium-review.googlesource.com/505264
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45387}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/8b49e99..ce01161

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/37015fb..d76621c

Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/87232d8..fd2abab

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: Iba04b2ab7b423bc49897de8f159f7960fd0813a3
Reviewed-on: https://chromium-review.googlesource.com/508332Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45386}

Port 11a211ff
Port 663a8ef4

Original Commit Message:

    Since the feedback vector is itself a native context structure, why
    not store optimized code for a function in there rather than in
    a map from native context to code? This allows us to get rid of
    the optimized code map in the SharedFunctionInfo, saving a pointer,
    and making lookup of any optimized code quicker.

    Original patch by Michael Stanton <mvstanton@chromium.org>

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6246,chromium:718891
LOG=N

Review-Url: https://codereview.chromium.org/2892663002
Cr-Commit-Position: refs/heads/master@{#45385}