R=ulan@chromium.org
BUG=chromium:693413

Change-Id: Ie8e6a5e20e904b81228b67f33c976569e305872c
Reviewed-on: https://chromium-review.googlesource.com/445157Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43319}

Unify the three different implementations of InferReceiverMaps, which
were basically copy&paste with slightly different optimizations applied
later into a single NodeProperties::InferReceiverMaps helper, which also
returns a ZoneHandleSet of maps, rather than only a single map.

BUG=v8:5267
R=jarin@chromium.org

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

Due to link-time optimizations functions with same code
can be folded into one, resulting in duplicate references.

R=jochen@chromium.org, peria@chromium.org
BUG=chromium:617892

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

BUG=chromium:693413

Change-Id: I6c6bc62e7f2c702be2462e4b0c3704fabf44f9d2
Reviewed-on: https://chromium-review.googlesource.com/445156
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43316}

This handles comparison operations (equality and relational) having
number feedback during the early type-hint lowering (i.e. during graph
construction).

R=bmeurer@chromium.org

Change-Id: I97afd6c0d78a790ce38b731f2532ca18d812a32c
Reviewed-on: https://chromium-review.googlesource.com/444766Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43315}

info.This returns a Local<Object>, which results in a call to
Utils::OpenHandle<JSReceiver>.  Casting to a Local<Value> first uses the
correct OpenHandle<Object> overload.

BUG=chromium:693500

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

By now lazy allocation of block scopes probably doesn't make that much sense anymore, since the memory overhead significantly reduced. Not indirecting scope() over ScopeState is faster, which is more important at this point.

BUG=v8:5209

Change-Id: I2968f01252769e7b1198a0a0876765a06ab0d3bd
Reviewed-on: https://chromium-review.googlesource.com/445025Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43313}

R=ahaas@chromium.org, mythria@chromium.org
BUG=

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

BUG=v8:5516
R=vogelheim@chromium.org

Change-Id: I7a39e49cc569b87064e5ac6764f4e3a65b2c6d11
Reviewed-on: https://chromium-review.googlesource.com/444765Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43311}

This makes it easier to implement asynchronous compilation by hiding all the implementation details of both synchronous and asynchronous compilation within wasm-module.cc, whereas before the code in wasm-js.cc actually implemented asynchronous compilation in terms of synchronous.

BUG=

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

BUG=693695

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

Revert of [interpreter] Create custom call opcodes for specific argument counts (patchset #13 id:240001 of https://codereview.chromium.org/2684993002/ )

Reason for revert:
Due to arm64 failures

Original issue's description:
> [interpreter] Create custom call opcodes for specific argument counts
>
> Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
> and CallProperty2. Also share the bytecode handler code between between
> equivalent CallX and CallPropertyX handlers.
>
> Review-Url: https://codereview.chromium.org/2684993002
> Cr-Commit-Position: refs/heads/master@{#43290}
> Committed: https://chromium.googlesource.com/v8/v8/+/00d6f1f80a00c4ac398af588dbd6815395791015

TBR=rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.

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

BUG=

Change-Id: Ib7cc2a04a7c8e314e1f4a8720eef569a6a4a3b18
Reviewed-on: https://chromium-review.googlesource.com/444406Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43307}

Remote objects don't have a creation context.

BUG=527190

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

BUG=

Change-Id: Ib82400e3a1b9d58257b26b8a5d7d22f5822d7a6c
Reviewed-on: https://chromium-review.googlesource.com/445084Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43305}

The constant field tracking is still disabled.

BUG=v8:5495

Change-Id: I543fe50b82e2255bbf200ea785ec53e3623e30cb
Reviewed-on: https://chromium-review.googlesource.com/440924
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43304}

Revert of [wasm] Embedder can control what buffers wasm compilation works on. (patchset #3 id:60001 of https://codereview.chromium.org/2699843003/ )

Reason for revert:
Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16427

Original issue's description:
> [wasm] Embedder can control what buffers wasm compilation works on.
>
> Two controls, one for instantiation and one for compilation. They allow
> the embedder (e.g. Chrome) check properties of the parameters of those
> two operations, and decide if they are allowed to continue.
>
> For example, Chrome may now decline compilation of certain size buffers,
> in synchronous cases; same for instantiation (where the buffer size
> refers to the size of the buffer containing wasm wire bytes)
>
> BUG=v8:5981
>
> Review-Url: https://codereview.chromium.org/2699843003
> Cr-Commit-Position: refs/heads/master@{#43295}
> Committed: https://chromium.googlesource.com/v8/v8/+/d9bc0ffb16e633d52d7bcfd547a6125f0e4dfb87

TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5981

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

Revert of [wasm] Identify wasm functions with index into the function tables. (patchset #7 id:110001 of https://codereview.chromium.org/2690113012/ )

Reason for revert:
Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/13707

Original issue's description:
> [wasm] Identify wasm functions with index into the function tables.
>
> Currently, the default name for wasm functions in generated code is 'wasm', tag wasm functions with the index into the function table to identify functions. Snippets of sample output with --print-code below.
>
> Before:
> --- Code ---
> kind = WASM_FUNCTION
> name = wasm
> compiler = turbofan
>
> After:
> --- Code ---
> kind = WASM_FUNCTION
> name = wasm#200
> compiler = turbofan
>
> R=mtrofin@chromium.org
>
> Review-Url: https://codereview.chromium.org/2690113012
> Cr-Commit-Position: refs/heads/master@{#43296}
> Committed: https://chromium.googlesource.com/v8/v8/+/5fc3ac29e4d942ccb4c45f6cdcee75d0b394b296

TBR=mtrofin@chromium.org,gdeepti@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/6d17aae..3e739fd

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

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

The bytecode generator did not necessarily know for which scope, and
thus language mode, it was generating code, because it only tracked
scopes that have a context.  This led to wrong behavior in some
examples involving class expressions (which are always in strict
mode).

With this CL, the bytecode generator explicitly tracks the current
scope, independent of whether it has a context.

BUG=v8:5927

Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b
Reviewed-on: https://chromium-review.googlesource.com/444785
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43300}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/35fe3e2..6d17aae

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/36a5082..84a7af6

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

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

Currently, typeof o, where o is an undetectable
callable object (such as document.all), returns 'function' if
optimised. It should, however, return 'undefined'.

This CL excludes undetectable objects from the optimization
resulting in type 'function' and renames the related code to
reflect that.

BUG=v8:5972
R=bmeurer@chromium.org

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1ecc6e7..35fe3e2

Rolling v8/test/wasm-js: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/b96d096..193fcb4

Rolling v8/tools/swarming_client: https://chromium.googlesource.com/external/swarming.client/+log/ebc8dab..11e31af

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

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

Currently, the default name for wasm functions in generated code is 'wasm', tag wasm functions with the index into the function table to identify functions. Snippets of sample output with --print-code below.

Before:
--- Code ---
kind = WASM_FUNCTION
name = wasm
compiler = turbofan

After:
--- Code ---
kind = WASM_FUNCTION
name = wasm#200
compiler = turbofan

R=mtrofin@chromium.org

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

Two controls, one for instantiation and one for compilation. They allow
the embedder (e.g. Chrome) check properties of the parameters of those
two operations, and decide if they are allowed to continue.

For example, Chrome may now decline compilation of certain size buffers,
in synchronous cases; same for instantiation (where the buffer size
refers to the size of the buffer containing wasm wire bytes)

BUG=v8:5981

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

Adds five new TF builtins for the spec defined functions/closures. This follows
mechanism similar to promise resolving functions approach where we store the
closure variables in a custom context.

Adds a new --harmony-promise-finally flag.

BUG=v8:5967

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

Failed instance migration should only be reported if the map of the
object was originally marked as deprecated. Otherwise it's pretty
confusing to investigate deoptimizations.

R=jarin@chromium.org

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

BUG=v8:5906
R=machenbach@chromium.org

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

Until recently, it sometimes did.

BUG=

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

Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.

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

This is the beginning of a new fuzzer that generates
correct-by-construction Wasm modules. This should allow us to better
exercise the compiler and correctness aspects of fuzzing. It is based off
of ahaas' original Wasm fuzzer.

At the moment, it can generate expressions made up of most binops, and
also nested blocks with unconditional breaks. Future CLs will add
additional constructs, such as br_if, loops, memory access, etc.

The way the fuzzer works is that it starts with an array of arbitrary
data provided by libfuzzer. It uses the data to generate an expression.
Care is taken to make use of the entire string. Basically, the
generator has a bunch of grammar-like rules for how to construct an
expression of a given type. For example, an i32 can be made by adding
two other i32s, or by wrapping an i64. The process then continues
recursively until all the data is consumed.

We generate an expression from a slice of data as follows:
* If the slice is less than or equal to the size of the type (e.g. 4
  bytes for i32), then it will emit the entire slice as a constant.
* Otherwise, it will consume the first 4 bytes of the slice and use
  this to select which rule to apply. Each rule then consumes the
  remainder of the slice in an appropriate way. For example:
  * Unary ops use the remainder of the slice to generate the argument.
  * Binary ops consume another four bytes and mod this with the length
    of the remaining slice to split the slice into two parts. Each of
    these subslices are then used to generate one of the arguments to
    the binop.
  * Blocks are basically like a unary op, but a stack of block types is
    maintained to facilitate branches. For blocks that end in a break,
    the first four bytes of a slice are used to select the break depth
    and the stack determines what type of expression to generate.
The goal is that once this generator is complete, it will provide a one
to one mapping between binary strings and valid Wasm modules.

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

BUG=

Change-Id: Ifc441739ef730a0b2278be0b662413c223631a72
Reviewed-on: https://chromium-review.googlesource.com/444190Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43288}

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

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

BUG=

Change-Id: I7efa4df72c6860120e3e9c090fcd666737b43749
Reviewed-on: https://chromium-review.googlesource.com/444786
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43286}

... which is used for initializing properties with non compile time values.

Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.

BUG=v8:5495, v8:4414

Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}

The functions do not work correctly with concurrent sweeper and they
do not take weak references into account.

The latter is a fundamental problem for this tracing approach.

BUG=

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

BUG=

Change-Id: I7542ada0eb557b5b813396f7d250549abb880f91
Reviewed-on: https://chromium-review.googlesource.com/444408
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43283}

Revert of [turbofan] extend escape analysis to reduce CheckMaps (patchset #7 id:140001 of https://codereview.chromium.org/2680973013/ )

Reason for revert:
Likely causing http://crbug.com/692254

BUG=chromium:692254

Original issue's description:
> [turbofan] extend escape analysis to reduce CheckMaps
>
> R=bmeurer@chromium.org
>
> BUG=
>
> Review-Url: https://codereview.chromium.org/2680973013
> Cr-Commit-Position: refs/heads/master@{#43163}
> Committed: https://chromium.googlesource.com/v8/v8/+/f01c8a6e4b24ab38e58bb141fc251bc6b75dbe21

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

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

Add `ValueSerializer::SetTreatArrayBufferViewsAsHostObjects()` which
instructs the `ValueSerializer` to treat ArrayBufferView objects as
host objects.

BUG=v8:5926

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

For results processor to work, we need to maintain the assumption that the cwd is equal to the currently running benchmark directory.

NOTRY=true
TBR=clemensh@chromium.org

Change-Id: I585c301dea846194652645973470786ad43aa280
Reviewed-on: https://chromium-review.googlesource.com/444784Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43280}