Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.

This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.

To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).

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

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

Port d412cfa2

Original commit message:
    [Atomics] Remove Atomics code stubs; use TF ops

    Reland of (https://codereview.chromium.org/1891033002)

    This is a much cleaner solution, which won't require nearly as much
    architecture-specific code. Thanks bmeurer@!

R=binji@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4614
LOG=N

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

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

Prior to 89d7bfda we always just collected the code offset and computed the
source position lazily. However, for local eval we already have the source
position ready, so we can just store that. For global eval we still have to
compute from the code offset. This CL changes the computation to be done only
on demand.

R=mstarzinger@chromium.org
BUG=chromium:604646
LOG=N

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

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

In addition to top source-destination pairs,
bytecode_dispatches_report.py now prints the hottest bytecode handlers
by the number of times they are executed and dispatch to another one,
regardless of the dispatch target.

Be aware that this figure does not match the number of times a handler
is executed for those which may not or will never dispatch, e.g.
Return or Throw.

BUG=v8:4899
LOG=N

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

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

This prepares a patch to throw actual errors instead of just strings on
wasm traps. In order to accomplish this, the messages need to be known
to the runtime, as the generated code will just pass the message id.

R=mstarzinger@chromium.org, titzer@chromium.org
BUG=

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

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

Without CL debugger on StepNext adds breakpoint to function where throw instruction is located. In case of StepNext we will skip pause in this function because StepNext shouldn't break in a deeper frame.

BUG=chromium:604495
R=yangguo@chromium.org
LOG=N

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

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

This is a bit unfortunate, but otherwise we would have to include
objects.h before message.h, since for the initialization of a Handle<T>,
the compiler checks that Object* can be assigned to T*. So it would
need to know about the inheritance for initializing Handle<Script> and
Handle<JSFunction>.

R=mstarzinger@chromium.org, titzer@chromium.org
BUG=

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

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

The guard in JSFunction::MarkForOptimization checking whether a function
is being debugged is overly protective. The compilation pipeline will
bailout itself in that circumstance. Having the runtime behave similar
makes sure the debugger observes a situation closer to reality.

R=yangguo@chromium.org

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

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

This cctest triggers a detailed stack trace containing WASM frames.

R=jfb@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
BUG=

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

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

This stops printing a log line for when a lookup in the optimized code
map did not yield a result. Logging such a negative result that will
inevitably trigger a compile anyways has little benefit and just spams
the console unnecessarily.

R=jkummerow@chromium.org

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

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

BUG=v8:4280
LOG=N

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

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

This makes them show up in the stack trace. Otherwise the stack frames
are identified as type STUB, and skipped by the iterator.

R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org
BUG=

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

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

As the code on the blink side sits down, we realize we don't need isolate arg
anymore. As the heap tracer is set per isolate, it can actually be confusing if
the isolate passed as argument is always the same as the isolate the heap tracer
was set for. Wdyt?

BUG=468240
LOG=no

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

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

Revert of 🏄 [heap] Add page evacuation mode for new->old (patchset #21 id:800001 of https://codereview.chromium.org/1863983002/ )

Reason for revert:
[Sheriff] Breaks:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/102

Original issue's description:
> [heap] Add page evacuation mode for new->old
>
> In a full mark-compact GC, instead of copying memory to old space for
> pages that have more than X% live bytes, we just move the whole page over to old
> space.
>
> X=70 (default value)
>
> BUG=chromium:581412
> LOG=N
>
> Committed: https://crrev.com/0d7e23a6edd3822970983030a77a5b80cd337911
> Cr-Commit-Position: refs/heads/master@{#35610}

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:581412

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

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

Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.

BUG=v8:4280
LOG=N

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

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

... such that they can be reused from other tests.

R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org
BUG=

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

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

This avoids custom compilation of receiver handlers for api getters.

BUG=

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

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

Till now, they were just skipped. With this patch, they now show up in
the DevTools on uncaught Errors with function name <WASM> and no line
number or file name information (see new test case:
https://chromiumcodereview.appspot.com/1875083002).

R=jfb@chromium.org, titzer@chromium.org
BUG=

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

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

BUG=v8:4437,v8:2899,chromium:604310
LOG=n

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

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

Port d412cfa2

BUG=

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

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

R=titzer@chromium.org

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

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

  port d2b0a4b7 (r35606)

  original commit message:
  MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

BUG=

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

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

In a full mark-compact GC, instead of copying memory to old space for
pages that have more than X% live bytes, we just move the whole page over to old
space.

X=70 (default value)

BUG=chromium:581412
LOG=N

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

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

This removes obsolete code that supports compiling without a shared
function info object. Even for top-level code compiled for live edit
such an object is allocated by now.

R=yangguo@chromium.org

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

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

The recursion does seem to help anything.

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

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

BUG=chromium:603463
LOG=N

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

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

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

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

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

This switches CodeGenerator::PrintCode to be based on the allocated
shared function info instead of the function literal. This is possible
now that even live edit allocates a shared function info for scripts.

R=ishell@chromium.org
BUG=chromium:604375
LOG=n

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

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

This makes IterateBodyFast work without requiring visitors to inherit from ObjectVisitor.

R=ishell@chromium.org

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

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

  port d412cfa2 (r35596)

  original commit message:
  Reland of (https://codereview.chromium.org/1891033002)

  This is a much cleaner solution, which won't require nearly as much
  architecture-specific code. Thanks bmeurer@!

BUG=

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

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

  port d0ccddd0 (r35584)

  original commit message:
  Behind --ignition-generators. Does not yet support Turbofan.

BUG=

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

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

If we have 2 phis with the exact same operand list, and the first phi is
used before the second one, via the operand incoming to the block
that defines the phi, and the second one's operand is defined (via a
parallel move) after the use, then the original operand will be assigned
to the first phi. This will lead to a spurious validation error.

To fix this, we look at the original pending assessment.

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

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

Port d0ccddd0

Original commit message:
       First version of the new generators implementation.

       Behind --ignition-generators. Does not yet support Turbofan.

R=neis@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, jyan@ca.ibm.com
BUG=v8:4907
LOG=N

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

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

Revert of 32-bit linux: Force 16-byte stack alignment. (patchset #1 id:1 of https://codereview.chromium.org/1899783002/ )

Reason for revert:
Broke InterpreterCreateArguments test on Linux nosnap debug:

https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/6404

Original issue's description:
> 32-bit linux: Force 16-byte stack alignment.
>
> clang assumes 16-byte stack alignment, but incoming stack alignment isn't
> always guaranteed to be that way.  It looks like v8 was lucky to not hit
> this so far.
>
> See https://crbug.com/418554 -- this makes v8's standalone config match
> Chromium.  See also https://llvm.org/bugs/show_bug.cgi?id=21414
>
> Maybe it's possible to change the caller of OnEntryHook() to guarantee
> the right alignment, but matching Chromium's build flags here seems like
> a good idea in general.
>
> BUG=v8:4928
> LOG=n
>
> Committed: https://crrev.com/3afb3324941625559635380ef98a2ee73e370a0a
> Cr-Commit-Position: refs/heads/master@{#35597}

TBR=machenbach@chromium.org,rnk@chromium.org,thakis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4928

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

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

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

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

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

clang assumes 16-byte stack alignment, but incoming stack alignment isn't
always guaranteed to be that way.  It looks like v8 was lucky to not hit
this so far.

See https://crbug.com/418554 -- this makes v8's standalone config match
Chromium.  See also https://llvm.org/bugs/show_bug.cgi?id=21414

Maybe it's possible to change the caller of OnEntryHook() to guarantee
the right alignment, but matching Chromium's build flags here seems like
a good idea in general.

BUG=v8:4928
LOG=n

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

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

Reland of (https://codereview.chromium.org/1891033002)

This is a much cleaner solution, which won't require nearly as much
architecture-specific code. Thanks bmeurer@!

BUG=v8:4614
LOG=y
TBR=bmeurer@chromium.org

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

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

Port 89d7bfda

Original commit message:
        There were a couple of issues with it:
        - interpreter is not supported
        - the source position was just accidentally correct for full-codegen
        - the eval origin could have been cached

        Also fixes a few other places to use AbstractCode.

R=yangguo@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=

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

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

Quick one, ptal.

BUG=468240
LOG=no

Committed: https://crrev.com/0eae5650dec265e961a1024fd2090301f2cdca16
Cr-Commit-Position: refs/heads/master@{#35578}

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

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

Change --harmony-exponentiation-operator to be enabled by default.

Intent-to-Ship: https://groups.google.com/forum/#!topic/v8-users/W6rKEsdQHXE

BUG=v8:3915
LOG=N
R=adamk@chromium.org, rossberg@chromium.org

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

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