Commit 26c00f4a improved the names of
most FAST_* elements kinds in the enum. This patch updates the matching
Has*Elements and Is*ElementsKind method names accordingly.

- HasFastSmiElements => HasSmiElements
- IsFastSmiElementsKind => IsSmiElementsKind
- HasFastObjectElements => HasObjectElements
- IsFastObjectElementsKind => IsObjectElementsKind
- HasFastSmiOrObjectElements => HasSmiOrObjectElements
- IsFastSmiOrObjectElementsKind => IsSmiOrObjectElementsKind
- HasFastDoubleElements => HasDoubleElements
- IsFastDoubleElementsKind => IsDoubleElementsKind
- HasFastHoleyElements => HasHoleyElements
- IsFastHoleyElementsKind => IsHoleyElementsKind

Additionally, FastHoleyElementsUsage is renamed to HoleyElementsUsage.

BUG=v8:6548

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie8f3d01eb43e909cbc6c372d88c5fbc4dfc2ac04
Reviewed-on: https://chromium-review.googlesource.com/558356Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46376}

The jsapi-harness test runs the JS-API spec tests of WebAssembly, which
get fetched from github when 'gclient sync' is executed. Without
'gclient sync' the harness may executed a version of the tests which is
older than required by the harness. In this CL I add a suggestion to
the test to run 'gclient sync' which is shown when the test is failing.

R=marja@chromium.org

Change-Id: I36d03bebc4d6cc554eefd4eb376c3d309b7ee5b9
Reviewed-on: https://chromium-review.googlesource.com/558419Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46375}

(The test that catches the bug was test-bytecode-generator/LookupSlot)

BUG=v8:5516

Change-Id: I00a02c5326b2a132383a9d72b5b894fade53bbf2
Reviewed-on: https://chromium-review.googlesource.com/558864
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46374}

This sometimes caused problems with bots (for node too) because the
allocation could fail.

Bug: v8:6452
Change-Id: I346a9117eba8b6ed41566efeceaf7fb190784d76
Reviewed-on: https://chromium-review.googlesource.com/558075Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46373}

Revert of [turbofan] Extend escape analysis to reduce certain CheckMaps. (patchset #1 id:1 of https://codereview.chromium.org/2964473002/ )

Reason for revert:
Speculative revert for tiny fire on Canary (crbug.com/738781)

Original issue's description:
> [turbofan] Extend escape analysis to reduce certain CheckMaps.
>
> Enable the experimental support in escape analysis to deal with
> constant-foldable CheckMaps nodes and remove them from the effect
> chain w/o blocking the scalar replacement of the object.
>
> BUG=v8:4586,v8:5267
> R=tebbi@chromium.org
>
> Review-Url: https://codereview.chromium.org/2964473002
> Cr-Commit-Position: refs/heads/master@{#46311}
> Committed: https://chromium.googlesource.com/v8/v8/+/adf7f54e24c4b31207b4df0e30c28f7579b18f5c

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

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/259d849..e9a4317

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/6d102fd..3b0c0e0

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/2023fc2..a89cc89

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

Change-Id: I5782e1de7c54ea4f2e1e5f637a4f166a5acc5bc6
Reviewed-on: https://chromium-review.googlesource.com/558413Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46371}

These were originally written as part of
https://chromium-review.googlesource.com/c/550396/. I've separated them
out into a separate CL with the intent of landing it first, so that it's
easier to see the difference these CLs will have on generated bytecode.

BUG=v8:5855
TBR=tebbi@chromium.org, rmcilroy@chromium.org

Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1
Reviewed-on: https://chromium-review.googlesource.com/558221Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46370}

Includes unit tests for the post-processing step
flatten_regions_to_parts().

Bug: v8:5244
TBR: bmeurer@chromium.org, rossberg@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I306dd1721cc00c5820b061f14c4b6866f8d938f6
Reviewed-on: https://chromium-review.googlesource.com/529973
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46369}

Bug: chromium:685318
Change-Id: Ia603ad4a0a35bba5c5572cad32364ff3695b3a74
Reviewed-on: https://chromium-review.googlesource.com/558191
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46368}

`IsHoleyElementsKind` doesn’t just check for holeyness — it checks for
dictionary elements as well. Its name should reflect that.

This patch renames `IsHoleyElementsKind` to
`IsHoleyOrDictionaryElementsKind`, which makes it possible to rename
`IsFastHoleyElementsKind` to `IsHoleyElementsKind` in a future patch.

R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548

Change-Id: Id799fe396442e9810426145359254d60990f8492
Reviewed-on: https://chromium-review.googlesource.com/558344Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46367}

This CL updates the wasm spec tests. In addition it adds an
assertNotEquals function to mjsunit.js, and it fixes the test harness
to not call quit() because it causes a dead-lock in combination with
async compilation.

R=rossberg@chromium.org

Change-Id: I50cf737993adb3e2bd27977efe7e20e304b89078
Reviewed-on: https://chromium-review.googlesource.com/558077Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46366}

...and cleanup definition of several builtins in %TypedArrayPrototype%.

Bug: v8:6459, chromium:737877
Change-Id: Ic5832847476bf5a544ae0b0df5df0ed4edd3e44c
Reviewed-on: https://chromium-review.googlesource.com/558076Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46365}

Replace the second level visitation with a much simpler logic that
just separately dispatches the special cases. All other cases can
use a dispatch that just evacuates an object based on size.

This is similar to the logic used in the mark-compact collector. The
goal is to align behaviors as much as possible, highlighting and 
fixing performance issues in the different behaviors.

This CL is mechanical as possible. A followup will clean
up the naming scheme and dispatching.

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

The CL adds optimizations for AddPair, SubPair, ShlPair, ShrPair and
SarPair macro instructions.

BUG=

Change-Id: I56460624adc0aa8ae135533ef4b99e0ed8360ccb
Reviewed-on: https://chromium-review.googlesource.com/555513Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46363}

- Properly detect whether the args.gn config actually wants goma.
- Read out cpu count dynamically.

NOTRY=true

Bug: 
Change-Id: I7a687e873ef0b009ab6eaada384378d23e1dbb1e
Reviewed-on: https://chromium-review.googlesource.com/558085
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46362}

The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.

This patch renames the FAST elements kinds as follows:

- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS

The following exceptions are left intact, for lack of a better name:

- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS

This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.

R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}

Allocates the Await success/failure closures, their context, and
the two required JSPromise objects all at once in a single call,
rather than performing multiple allocations throughout the function.

Saves about 2kb of snapshot space on an x64.release build.

Performance impact of this change has not been measured yet.

BUG=v8:4483
R=ishell@chromium.org, jgruber@chromium.org

Change-Id: I8d911cb91f5d0e00544ad3ba608aa170f6b2f704
Reviewed-on: https://chromium-review.googlesource.com/549999Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46360}

Add support for MSA I5 instructions in mips32 and mips64 simulators.

Bug: 
Change-Id: Ie1be499a1b3c686603348d895456b8f39d5c1002
Reviewed-on: https://chromium-review.googlesource.com/552554Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46359}

Catch prediction for optimized frames had two issues:

Inlined frames were iterated from caller-to-callee (which could
result in incorrect predictions if one frame predicted CAUGHT and
another predicted PROMISE).

When encountering a builtin frame, we'd unconditionally return its
prediction (which is wrong if it predicted UNCAUGHT and another inlined
frame predicted either CAUGHT or PROMISE).

This CL fixes both issues and refactors the function to reduce nesting.

BUG=v8:6536

Change-Id: I764a4ec033e4476bd840134b5eacfe0e08b3c1a4
Reviewed-on: https://chromium-review.googlesource.com/555519
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46358}

V8's catch prediction mechanism tries to predict whether a thrown
exception will be caught, just by looking at the current call stack.

At the time when catch prediction was first introduced, only a few
builtins (mostly related to Promise and Generator) could end up being
fed into the catch prediction mechanism. This is no longer the case now
that builtins are used in new ways, e.g. Array.p.forEach's continuation
builtins.

This CL removes the need to explicitly mark all builtins visible to the
StackFrameIterator as CAUGHT/UNCAUGHT/PROMISE, and instead defaults to
treating unmarked builtins as UNCAUGHT.

BUG=v8:6536

Change-Id: Ibdc106a91b2b0ffb93099433077642cad02c71e2
Reviewed-on: https://chromium-review.googlesource.com/555518
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46357}

... and set the instance class name in a bootstrapper instead.

Change-Id: Ie8a9a0e7cdc22ca19616b4a0d09665e059cd4d3e
Reviewed-on: https://chromium-review.googlesource.com/557864Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46356}

With FCG no longer able to deoptimize, we can remove the "push" version
of output frame state combine, as deoptimisation to bytecode is always
the PokeAt variant.

Bug: v8:6409
Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
Reviewed-on: https://chromium-review.googlesource.com/557866
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46355}

Building on Windows with gyp fails depending on the result from
sharding the src/v8.gyp:v8_base target. If two source files with the
same name are in the same shard, their output object file path would
conflict with one another. One example of this conflict is v8_base's
runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that
is generated at build time, for which the files runtime.obj and
Runtime.obj would be created, but MSVS overwrites one of them with
the other.

Dividing the .obj output path by the original source's extension
prevents this overwrite.

Refs: https://github.com/nodejs/node/pull/13959
Bug: 
Change-Id: I158e6178f2511297899ee50ea159f574916f903f
Reviewed-on: https://chromium-review.googlesource.com/556599Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46354}

This reverts commit 1520a851.

Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.

Original change's description:
> [wasm] Run foreground compilation tasks as normal tasks
> 
> This CL makes foreground compilation tasks normal (i.e. not cancelable)
> again, because otherwise a deadlock can happen. I think the reason why
> the foreground tasks were cancelable was to make sure that all tasks
> either finish correctly or get canceled. However, since the isolate can
> only shut down on the main thread, this means that the foreground task
> should have already finished when the isolate shuts down, or it should
> not have started at all. I reordered the deletion of the AsyncCompileJob
> though to make sure that an AsyncCompileJob is removed from
> CompilationManager before its promise is resolved.
> 
> Here is the deadlock: The JS code which is executed after a promise is
> resolved is executed within the task which resolves the promise. In case
> of async compilation this means that some JS code is executed within a
> CompileTask. In JS, the shutdown of the isolate can be triggered. During
> the shutdown of the isolate, the CancelableTaskManager waits for all
> registered cancelable tasks to complete, including the CompileTask of
> async compilation. This means that the CancelableTaskManager waits for
> itself to finish, which is a deadlock.
> 
> R=​clemensh@chromium.org, mtrofin@chromium.org
> 
> Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
> Reviewed-on: https://chromium-review.googlesource.com/554733
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46343}

TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org

Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558284Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46353}

This CL landed on top of another CL which I want to revert.

This reverts commit 27b0d6a9.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> [wasm] Update spec tests
> 
> Update the spec tests in v8 to the most recent version.
> 
> R=​rossberg@chromium.org
> CC=titzer@chromium.org
> 
> Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
> Reviewed-on: https://chromium-review.googlesource.com/552155
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46346}

TBR=mstarzinger@chromium.org,rossberg@chromium.org,ahaas@chromium.org

Change-Id: I82e4a2887bcb867d3572b78c36a20adc05df0903
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558040Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46352}

It can happen that coverage infos for a function containing
IncBlockCounter bytecodes can be deleted (e.g. by switching to
best-effort coverage). Handle this case correctly in the IncBlockCounter
runtime function.

BUG=v8:6000

Change-Id: I49b9f52822661150d55410d6b173b3929adf4af2
Reviewed-on: https://chromium-review.googlesource.com/558039
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46351}

This reverts commit ca931562.

Reason for revert: tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/16007

Original change's description:
> [wasm] Allow the initialization of a single compilation unit
> 
> This CL adds a new function {InitializeCompilationUnit} to initialize
> a single compilation unit and not just all compilation units at once.
> This is necessary for streaming compilation eventually. This also
> required some refactoring on how the working queue for compilation units
> works. Previously the synchronization was done with an atomic counter,
> now it is done with a lock. Note that the code to finish compilation
> of a module still only works if the working queue gets only empty when
> all work is done. I plan to change this in a different CL.
> 
> Since the code would not be tested without streaming compilation, I added
> an experimental flag and a test to test the new code.
> 
> R=​clemensh@chromium.org, mtrofin@chromium.org
> 
> Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
> Reviewed-on: https://chromium-review.googlesource.com/550096
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46348}

TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org

Change-Id: Ied6532f05463c0b78c8b8f5307d44640bcca8316
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558224Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46350}

This reverts commit 0d2ed6c3.

The CL introduced perf regressions: crbug.com/735649.

We are going to reland the CL in an isolated V8 roll to ensure
that perf regressions are attributed correctly.

Original commit message:
> [heap] Allow a minimum semi-space size of 512K.
> This CL also reduces the minimum semi-space size to 512K.
> BUG=chromium:716032

BUG=chromium:735649

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1f1b08ca6853347c00070f000c309d839ff8a4bb
Reviewed-on: https://chromium-review.googlesource.com/552541Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46349}

This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.

Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.

R=clemensh@chromium.org, mtrofin@chromium.org

Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
Reviewed-on: https://chromium-review.googlesource.com/550096
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46348}

This way, each lazy function needs to handle only the data relevant to
itself. This reduced data handling overheads.

Other changes:

1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
function compilation is only done in the main thread.

2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:

- The data looks fundamentally different when we're producing it and when we're
  consuming it.

- Cleanly separates the operations we can do in the "producing phase" and in the
  "consuming phase".

Bug: v8:5516
Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
Reviewed-on: https://chromium-review.googlesource.com/528094
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46347}

Update the spec tests in v8 to the most recent version.

R=rossberg@chromium.org
CC=titzer@chromium.org

Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
Reviewed-on: https://chromium-review.googlesource.com/552155
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46346}

BUG=chromium:738031

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

Last marker to use the instance based visitors. Delete StaticMarkingVisitor.

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

This CL makes foreground compilation tasks normal (i.e. not cancelable)
again, because otherwise a deadlock can happen. I think the reason why
the foreground tasks were cancelable was to make sure that all tasks
either finish correctly or get canceled. However, since the isolate can
only shut down on the main thread, this means that the foreground task
should have already finished when the isolate shuts down, or it should
not have started at all. I reordered the deletion of the AsyncCompileJob
though to make sure that an AsyncCompileJob is removed from
CompilationManager before its promise is resolved.

Here is the deadlock: The JS code which is executed after a promise is
resolved is executed within the task which resolves the promise. In case
of async compilation this means that some JS code is executed within a
CompileTask. In JS, the shutdown of the isolate can be triggered. During
the shutdown of the isolate, the CancelableTaskManager waits for all
registered cancelable tasks to complete, including the CompileTask of
async compilation. This means that the CancelableTaskManager waits for
itself to finish, which is a deadlock.

R=clemensh@chromium.org, mtrofin@chromium.org

Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
Reviewed-on: https://chromium-review.googlesource.com/554733
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46343}

This mostly reverts commit c503b805 but fixes
an issue where literals would always be pretenured on first instantiation.

As a cleanup we pass in a PretenureFlag instead of using the FeedbackVector as
indicator.

Bug: v8:6211
Change-Id: Id328552620e33f5083519bcba1e24396d162d516
Reviewed-on: https://chromium-review.googlesource.com/555670Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46342}

Pass the_hole_value as a |prototype| to let the helper function create
prototype object and properly wire it with the respective constructor
function.

Bug: v8:6459
Change-Id: I85097c02c88f00a47e62321ee3e6a3bdf6b5bcf8
Reviewed-on: https://chromium-review.googlesource.com/557799Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46341}

The CL adds optimizations for Neg_s and Neg_d macro instructions.

BUG=

Change-Id: I842480ac3195860a1a36dadcffb5dc560ca8f424
Reviewed-on: https://chromium-review.googlesource.com/555131Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46340}

Similar to JSCall, we can also replace uninitialized JSConstruct nodes
with SOFT deopts to ensure that we don't generate unnecessary dead code.
This for example shows up in the hot parts of the Node event emitter
currently where the generic code for handling events with 4 or more
parameters might not have been run, but we still generate most of the
code because the new Array call in the beginning is not turned into
a SOFT deopt immediately.

Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of
Construct bytecodes a bit to reduce the amount of code duplication.

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

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

Change-Id: I2ee0ff9db1bbc8c17a1ad3dea1de1ad996895852
Reviewed-on: https://chromium-review.googlesource.com/474807Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46338}

Extend the use list check for the arguments object/rest parameters
during apply/spread optimization to allow for more cases, such that
even in code like

  function foo() {
    if (arguments.length === 1) return arguments[0];
    return bar.apply(this, arguments);
  }

we don't need to materialize the arguments object. This obviously comes
with a phase ordering problem, which we resolve by introducing a
waitlist in the JSCallReducer, which contains the nodes that we should
check again after all the other reductions are done, and which might
then be reducible. This is not 100% ideal, but get's us closer to where
we want to be, and it's crucial to speed up Node core, especially the
event emitter.

BUG=v8:4551,v8:5511, v8:5726
R=petermarshall@chromium.org

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