Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1643533003

Cr-Commit-Position: refs/heads/master@{#33556}

Implement the optional turbofan operators Word32Ctz, Word64Ctz, Word32Popcnt and Word64Popcnt.

BUG=

Review URL: https://codereview.chromium.org/1588383002

Cr-Commit-Position: refs/heads/master@{#33555}

R=jarin@chromium.org
BUG=v8:4583
LOG=n

Review URL: https://codereview.chromium.org/1642653002

Cr-Commit-Position: refs/heads/master@{#33554}

TEST=mjsunit/harmony/unicode-regexp-ignore-case
BUG=

Review URL: https://codereview.chromium.org/1639263002

Cr-Commit-Position: refs/heads/master@{#33553}

This reverts commit 85ba94f2.

All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

Review URL: https://codereview.chromium.org/1640563004

Cr-Commit-Position: refs/heads/master@{#33552}

BUG=chromium:580584
LOG=y

Review URL: https://codereview.chromium.org/1632603002

Cr-Commit-Position: refs/heads/master@{#33551}

R=erik.corry@gmail.com
BUG=v8:2952
LOG=N

Review URL: https://codereview.chromium.org/1630633002

Cr-Commit-Position: refs/heads/master@{#33550}

  port 6131ab1e (r33509)

  original commit message:
  This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
  When debugger is active tail calls are disabled.

  Tail calling can be enabled by --harmony-tailcalls flag.

BUG=

Review URL: https://codereview.chromium.org/1637163003

Cr-Commit-Position: refs/heads/master@{#33549}

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1642613002

Cr-Commit-Position: refs/heads/master@{#33548}

Cr-Commit-Position: refs/heads/master@{#33547}

BUG=
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1638333002

Cr-Commit-Position: refs/heads/master@{#33546}

This ensures that the BytecodeGraphBuilder can generate correct graphs
even when deoptimization has not been enabled. This configuration is not
enabled in production, and we might eventually decide to deprecate it
for good. Until then, this is a quick fix.

R=jarin@chromium.org
TEST=cctest/test-pipeline

Review URL: https://codereview.chromium.org/1640683002

Cr-Commit-Position: refs/heads/master@{#33545}

Introduces the concept of transfer direction to register operands. This
enables the register translator to emit exactly the moves that a
bytecode having it's register operands translated needs.

BUG=v8:4280,v8:4675
LOG=N

Review URL: https://codereview.chromium.org/1633153002

Cr-Commit-Position: refs/heads/master@{#33544}

We only do the desugaring in RegExpCharacterClass::ToNode, which is not
called if it is part of a RegExpText.

R=erik.corry@gmail.com, erikcorry@chromium.org

Review URL: https://codereview.chromium.org/1641593002

Cr-Commit-Position: refs/heads/master@{#33543}

BUG=v8:4586
LOG=n

Review URL: https://codereview.chromium.org/1631333002

Cr-Commit-Position: refs/heads/master@{#33542}

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

Review URL: https://codereview.chromium.org/1637923002

Cr-Commit-Position: refs/heads/master@{#33541}

R=littledan@chromium.org
BUG=v8:2952
LOG=N

Review URL: https://codereview.chromium.org/1601653006

Cr-Commit-Position: refs/heads/master@{#33540}

Revert of [heap] Parallel newspace evacuation, semispace copy, and compaction \o/ (patchset #16 id:620001 of https://codereview.chromium.org/1577853007/ )

Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664

Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
>  - semispace copy: from space -> to space (within newspace)
>  - newspace evacuation: newspace -> oldspace
>  - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
>  - The hard cap on number of tasks has been lifted
>  - We cache store buffer entries locally before merging them back into the global
>    StoreBuffer in a finalization phase.
>  - We cache AllocationSite operations locally before merging them back into the
>    global pretenuring storage in a finalization phase.
>  - AllocationSite might be compacted while they would be needed for newspace
>    evacuation. To mitigate any problems we defer checking allocation sites for
>    newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}

TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

Review URL: https://codereview.chromium.org/1643473002

Cr-Commit-Position: refs/heads/master@{#33539}

BUG=v8:2952
LOG=N

Review URL: https://codereview.chromium.org/1599303002

Cr-Commit-Position: refs/heads/master@{#33538}

In a generator function, the parser rewrites a return statement into a "final"
yield.  A final yield used to close the generator, which was incorrect because
the return may occur inside a try-finally clause and so the generator may not
yet terminate.

BUG=

Review URL: https://codereview.chromium.org/1634553002

Cr-Commit-Position: refs/heads/master@{#33537}

MoveKey used to be a std::pair. Rather than expecting the reader to
remember which is "first" and "second", this change makes it a struct
with specific names ("source" and "destination")

BUG=

Review URL: https://codereview.chromium.org/1641523002

Cr-Commit-Position: refs/heads/master@{#33536}

On Intel, imul clobbers {r|e}ax.  We're missing that in the representation
of the MulHigh intermediate instructions. Fixing, by adding it as a temp,
akin VisitDiv does.

Review URL: https://codereview.chromium.org/1631973003

Cr-Commit-Position: refs/heads/master@{#33535}

This patch stages the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being staged separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.

R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y

Review URL: https://codereview.chromium.org/1637703003

Cr-Commit-Position: refs/heads/master@{#33534}

Field types can contain at most one map, so we can just use IsClass().

Review URL: https://codereview.chromium.org/1633213003

Cr-Commit-Position: refs/heads/master@{#33533}

Rolling v8/buildtools to 11961c21510b90aa6057064459a1af53f3fff449

Rolling v8/tools/clang to 55e0efc650db1b2c60b50c8c32cfc8a27d8f2986

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

Review URL: https://codereview.chromium.org/1641473002

Cr-Commit-Position: refs/heads/master@{#33532}

Functions like DataView.prototype.getUint8 should have length 1,
and DataView.prototype.setUint8 should have length 2, as their
endianness arguments are optional. Additionally,
TypedArray.prototype.set.length should be 2. This follows the ES2015
specification, and a new test262 test tests for it. This patch
fixes the functions' lengths.

R=adamk

Review URL: https://codereview.chromium.org/1636953003

Cr-Commit-Position: refs/heads/master@{#33531}

ParseArrowFunctionLiteral was erroneously checking AllowsLazyCompilation
rather than AllowsLazyParsing when deciding whether to parse lazily.
This meant that lexically-scoped variables that had no other referents
wouldn't get closed over properly.

BUG=chromium:580934, v8:4255
LOG=y

Review URL: https://codereview.chromium.org/1630823006

Cr-Commit-Position: refs/heads/master@{#33530}

This makes it easier to see what behavior each test is verifying.

BUG=v8:3699
LOG=n

Review URL: https://codereview.chromium.org/1638853003

Cr-Commit-Position: refs/heads/master@{#33529}

They were already treated as a BindingPattern error; this patch simply
replaces that call with one marking them as both a binding and assignment
error, and adds parsing tests for both cases.

BUG=v8:4707
LOG=n

Review URL: https://codereview.chromium.org/1632303002

Cr-Commit-Position: refs/heads/master@{#33528}

It allows embedder to inject a stack sample on demand.

BUG=chromium:579191
LOG=N

Review URL: https://codereview.chromium.org/1631043002

Cr-Commit-Position: refs/heads/master@{#33527}

CAN_USE_VFP_INSTRUCTIONS was removed in GYP in
https://codereview.chromium.org/340373002

BUG=None
LOG=Y

Review URL: https://codereview.chromium.org/1635123003

Cr-Commit-Position: refs/heads/master@{#33526}

Implements do expressions for the Ignition.

BUG=v8:4685
LOG=N

Review URL: https://codereview.chromium.org/1632213002

Cr-Commit-Position: refs/heads/master@{#33525}

Port 6131ab1e

Original commit message:
    This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
    When debugger is active tail calls are disabled.

    Tail calling can be enabled by --harmony-tailcalls flag.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4698
LOG=Y

Review URL: https://codereview.chromium.org/1635823003

Cr-Commit-Position: refs/heads/master@{#33524}

All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

Review URL: https://codereview.chromium.org/1577853007

Cr-Commit-Position: refs/heads/master@{#33523}

A statement could have several break positions. The entire statement
should be considered muted if break points across all these break
positions evaluate to false.

R=verwaest@chromium.org
BUG=chromium:429167
LOG=N

Review URL: https://codereview.chromium.org/1615903002

Cr-Commit-Position: refs/heads/master@{#33522}

This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.

The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.

TBR=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1636013002

Cr-Commit-Position: refs/heads/master@{#33521}

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1632993003

Cr-Commit-Position: refs/heads/master@{#33520}

Add S390 specific atomic ops implementation + associated build
toolchain updates.

R=danno@chromium.org,svenpanne@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,mtbrandyberry@ca.ibm.com

BUG=

Review URL: https://codereview.chromium.org/1601223003

Cr-Commit-Position: refs/heads/master@{#33519}

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1563213002

Cr-Commit-Position: refs/heads/master@{#33518}

BUG=v8:4280
LOG=N
TBR=machenbach@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/1633133002

Cr-Commit-Position: refs/heads/master@{#33517}