The PrepareId bailout location was used incorrectly in Crankshaft and,
as it turns out, is not required anyway (once you do it right). Also
there was some premature optimization going on with the CheckEnumCache
(trying to load null from roots only once), plus we can be smarter about
the null/undefined check anyway.

The idea behind this changes is to prepare unification of the two
different ForInPrepare implementations that we now have, with the end
result being that we only use the new implementation that was recently
added for the interpreter.

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

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

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

  port 0b3066b8 (r33414)

  original commit message:
  This implements a first prototype of stack unwinding for interpreted
  frames. The unwinding machinery performs a range-based lookup in the
  given handler table and potentially continues dispatching at the handler
  offset. Note that this does not yet correctly restore the context to the
  correct value when the handler is being entered.

BUG=

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

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

  port 2dde677f (r33386)

  original commit message:
  This is the ia32/x64 version of https://codereview.chromium.org/873703002,
  which fixed the same problem on arm/arm64.

BUG=

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

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

  port d1d01964 (r33410)

  original commit message:
  The motivation for this is that CompilationInfo really shouldn't
  explicitly know anything about CodeStubs. This is evident in
  the TurboFan stubs pipeline, which only needs to pass down
  information about Code::Flags to the code generator and not
  any of the CallInterfaceDescriptor silliness that Hydrogen has
  to push around, since TF has the Linkage class that
  encapsulates everything that is needed for the stub ABI. So,
  instead of threading CodeStub machinery through the TF stub
  pipeline, it is now removed from CompilationInfo and replaced
  by only the explicit bits needed both by the Crankshaft and
  TF pipelines in code generation.

BUG=

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

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

Rolling v8/build/gyp to aa0301be5a241c2972f90ce2a08097b63c916390

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

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

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

R=titzer@chromium.org,aseemgarg@chromium.org
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator, asm-wasm.js
LOG=N

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

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

Although the `for..in` statement allows Expressions to define the
iterator, only an AssignmentExpression may occupy this position in the
`for..of` statement.

BUG=v8:4692
LOG=N
R=adamk@chromium.org

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

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

Remove an unnecessary is_static argument to ParsePropertyName (the caller
already has easy access to that information) and inline
ParseIdentifierNameOrGetOrSet into its only caller.

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

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

Port 0b3066b8

Original commit message:
    This implements a first prototype of stack unwinding for interpreted
    frames. The unwinding machinery performs a range-based lookup in the
    given handler table and potentially continues dispatching at the handler
    offset. Note that this does not yet correctly restore the context to the
    correct value when the handler is being entered.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4674
LOG=n

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

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

The Object.getOwnPropertyNames method always calls into C++ anyway,
so there's no point in having the JavaScript wrapper around at all.

Drive-by-fix: Inline GetOwnEnumerablePropertyNames into its single
call site.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_rel_ng
R=yangguo@chromium.org

Committed: https://crrev.com/bf027fe756f62b4abcac8aa08134c8c5ed055620
Cr-Commit-Position: refs/heads/master@{#33380}

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

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

We no longer have the concept of "JS builtins" exposed to handwritten
native code, so there's no need to keep the InvokeBuiltin macro around.

R=mstarzinger@chromium.org

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

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

This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_rel_ng
R=yangguo@chromium.org

Committed: https://crrev.com/ffa9e82235b20c523ebb1151c6196bc6232296b9
Cr-Commit-Position: refs/heads/master@{#33398}

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

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

This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.

R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n

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

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

Up to now, for ranges spilled in deferred blocks, we would spill every
time a range would switch from using a register to spill slots. That can
be redundant, leading to avoidable code size  cost.

This change addresses this issue, by performing the spills as early as
possible.

BUG=

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

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

Platforms which do not provide rounding instructions (like x64 without
sse4.1, arm before v8) fall back to this new soft float inplementation.

BUG=575379

LOG=Y

R=titzer@chromium.org

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

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

R=ahaas@chromium.org,bradnelson@chromium.org
LOG=Y
BUG=chromium:575167

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

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

The motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.

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

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

R=mstarzinger@chromium.org
BUG=v8:4690
LOG=N

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

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

This is to fix some of the failing test262 tests with ignition flag.
In few test262 tests, there is a throw from the script scope. Rewriter::Rewrite
pass converts expression statements into assignment statements in script scope.
This causes interpreter to fail because assignment expression expects a result
in accumulator but throw statement does not return a value. To fix this, we
now mark that accumulator contains a value when visiting throw statement.

BUG=v8:4280
LOG=N

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

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

Where possible:
- eliminate special-case code generation for simulator.
- eliminate #ifdefs.

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

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

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

* Treat Select nodes as escaping
* Correctly void virtual field information
  after a store to a non-const index
* Add a shortcut if all allocates escape
* Add a shortcut if no allocates are discovered
* Only reduce FrameState/StateValues nodes if they
  have virtual allocates as input (transitively)
* Fix bug in FrameState/StateValues duplication
* Add check to verifier: First 3 inputs of FrameState
  must be StateValues

R=mstarzinger@chromium.org
BUG=v8:4586
LOG=n

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

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

Currently we fail to properly handle shadowed properties. If the
receiver defines a non-enumerable property that reappears on the
prototype as enumerable it incorrectly shows up in [[Enumerate]].
By extending the KeyAccumulator to track non-enumerable properties
we can now properly filter them out when seeing them further up in
the prototype-chain.

BUG=v8:705
LOG=y

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

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

Revert of [builtins] Migrate Object.getOwnPropertyDescriptor to C++. (patchset #1 id:1 of https://codereview.chromium.org/1606783002/ )

Reason for revert:
Breaks roll: https://codereview.chromium.org/1603953002/

Original issue's description:
> [builtins] Migrate Object.getOwnPropertyDescriptor to C++.
>
> The implementation of Object.getOwnPropertyDescriptor always called into
> C++ anyway, so there's no need to have this JavaScript wrapper around at
> all.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3fdd37b028f4711d0f6dcb038f575ce08ef0cfa3
> Cr-Commit-Position: refs/heads/master@{#33379}

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

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

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

Revert of [runtime] Introduce maps for the likely cases of FromPropertyDescriptor. (patchset #1 id:1 of https://codereview.chromium.org/1607943003/ )

Reason for revert:
Predecessor CL suspect for roll breakage: https://codereview.chromium.org/1610563002

Original issue's description:
> [runtime] Introduce maps for the likely cases of FromPropertyDescriptor.
>
> This change improves performance for the common case of
> Object.getOwnPropertyDescriptor by up 3x-4x, where we just
> return a property descriptor object for a regular data or
> accessor property.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/ffa9e82235b20c523ebb1151c6196bc6232296b9
> Cr-Commit-Position: refs/heads/master@{#33398}

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

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

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

This removes the above flag definition. The flag is no longer needed as
the default implementation is more than capable of faking presence of
handling of try-catch and try-finally constructs by now.

R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n

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

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

R=oth@chromium.org

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

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

This implements a first version of exception handler table construction
within the interpreter. Note that the local control flow for try-catch
and try-finally statements is still off, and also stack unwinding does
not yet respect interpreter frames. But generated handler tables should
be populated correctly already.

R=oth@chromium.org
BUG=v8:4674
LOG=n

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

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

Revert of [runtime] Migrate Object.getOwnPropertyNames to C++. (patchset #2 id:20001 of https://codereview.chromium.org/1605803002/ )

Reason for revert:
Breaks roll: https://codereview.chromium.org/1603953002/

Original issue's description:
> [runtime] Migrate Object.getOwnPropertyNames to C++.
>
> The Object.getOwnPropertyNames method always calls into C++ anyway,
> so there's no point in having the JavaScript wrapper around at all.
>
> Drive-by-fix: Inline GetOwnEnumerablePropertyNames into its single
> call site.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/bf027fe756f62b4abcac8aa08134c8c5ed055620
> Cr-Commit-Position: refs/heads/master@{#33380}

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

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

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

This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.

R=yangguo@chromium.org

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

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

Rolling v8/tools/clang to 9c45873bbb82dc33f5f88f5c7dbc06ee9ecc7e8f

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

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

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

The old handling of escaped keywords erroneously treated escaped versions
of "let" and "static" as ESCAPED_KEYWORD, leading to erroneous errors in
sloppy mode. Moreover, though the class literal parsing code attempted
to fix up the parsing of escaped versions of "static" to allow it in the
right places, that code wasn't complete.

Fixing the scanner to mark escaped "static" as ESCAPED_STRICT_RESERVED_WORD
allows simplifying the class literal parsing code. A little extra code
was needed to properly handle the new treatment of escaped "let".

Note that "yield" is still broken (that is, we're overly restrictive of
escaped "yield" in sloppy mode).

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

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

The dust has settled and it can now be used like any other header file

R=mstarzinger@chromium.org

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

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

Revert of Tenure descriptor arrays. (patchset #1 id:1 of https://codereview.chromium.org/1526663002/ )

Reason for revert:
Regresses memory consumption.

BUG=571180,571657
LOG=n

Original issue's description:
> Tenure descriptor arrays.
>
> BUG=
>
> Committed: https://crrev.com/74bc69166de8cfb967e79b5c8cc31c2a76490dc8
> Cr-Commit-Position: refs/heads/master@{#32846}

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

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

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

This patch implements one aspect of ES2015 RegExp subclassing:
String.prototype.replace is separated into two parts, a method on
RegExp.prototype in case the first argument is a RegExp, and the
String.prototype.replace method, which handles the string pattern
case. This separation is described in the ES2015 specification.
Most of the patch is simply moving code from string.js to regexp.js.

R=yangguo
LOG=Y
BUG=v8:4343

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

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

Port fc53eed1

Original commit message:
    The new operator converts a float32 input to int32 through truncation.

R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

BUG=chromium:535160
LOG=n
TBR=tandrii@chromium.org

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

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

BUG=

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

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

o Adds wide variants of bytecodes that have operands describing ranges
  of registers. The upcoming wide register support does not suppport
  re-mapping ranges.
o Adds kRegPair16 and kRegTriple16 operands required for new wide
  bytecodes and renames Count8/Count16 operands to RegCount8/RegCount16.
o Removes Exchange bytecodes

BUG=v8:4675
LOG=NO

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

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

Fixes a bug where the context would be popped before labeled block break target
location.

BUG=v8:4280
LOG=N

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

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

Newly added tests cctest/test-run-wasm-js/Run_JSSelect_0...6 cause failures
on MIPS bigendian and are skipped until a solution is found.

BUG=

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

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