Now TurboFan always uses the newly introduced %ForInPrepare, no matter
whether baseline is the interpreter or fullcodegen. For fullcodegen, we
introduce a new PrepareId bailout point for this purpose.

Drive-by-fix: Avoid the NoObservableSideEffectsScope in Crankshaft and
use the PrepareId bailout point instead.

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

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

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

Rolling v8/buildtools to 222bd42ce39d1bd8f08fe089b066f49c469e1cdf

Rolling v8/tools/clang to 3ed46b50b0b4e8c829ea6492bbe357b2b7b8e64a

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

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

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

The web appears to depend on being able to redeclare functions-in-blocks
in sloppy mode (examples seen so far tend to redeclare identical functions,
most likely accidentally).

This patch opens a minimal hole: two same-named function declarations
in the same scope are allowed, only in sloppy mode.

BUG=v8:4693, chromium:579395
LOG=y

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

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

Change the interpreter to always store the current context in the frame's
context slot instead of the function context. This makes it possible to
restore the correct context during deopt.

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

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

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

Port a0878333

Original commit message:
    We already had hand-written optimized code for %_ToName in fullcodegen,
    but the optimizing compilers always went to the runtime for %_ToName,
    which is pretty bad for many of our builtins. So this CL moves the
    existing native code to a ToNameStub (similar to the existing
    ToStringStub), and uses the ToNameStub consistently in all compilers to
    actually implement %_ToName.

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

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

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

This change allows the PPC simulator to execute on PPC hardware where,
due to calling conventions, we must distinguish between Object* and
ObjectPair return values.

We find this useful as another available option for debugging certain
problems.  While not strictly necessary for Intel platforms, we hope
that this is less offensive now that BUILTIN_CALL_TRIPLE has been
added.

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

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

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

These tests have been disabled while support for try-finally was work in
progress. By now control flow is connected properly and the tests pass.

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

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

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

Revert "Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ )"

This reverts commit 77df8659.

BUG=

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

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

This adds an explicit ReThrow bytecode to be used in the modelling of
try-finally statements. An exception that is being re-thrown should not
trigger message object creation or location computation and hence cannot
use the existing Throw bytecode.

R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryFinally
BUG=v8:4674
LOG=n

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

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

Port ca51c204

Original commit message:
    This fixes the broken return address when the exception handler within
    interpreted bytecode is being entered via stack unwinding. The address
    in question will never actually be taken, but our stack walker uses this
    address to determine whether a frame is interpreted.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
TEST=cctest/test-interpreter/InterpreterTryCatch
BUG=v8:4674
LOG=n

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

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

Adds support for ForOf to the interpreter.

BUG=v8:4685
LOG=N

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

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

In case the receiver map has an enum cache, %ForInPrepare returns the
length of the actual enum cache, which might include properties that
are further down the transition tree tho.

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

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

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

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

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

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

Is it frozen water? Is it a train? No, but it's both (relatively) fast and
(relatively) cool, it's ICE, the IC-Explorer. Upload an IC trace and you can
easily* drill-down on where most IC changes happen. It even comes with a colored
title and runs in your favourite browser without dependencies (yeah, I'm looking
at you JQuery!)

*according to a user study with a random 1-person group.

R=mvstanton@chromium.org
BUG=

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

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

TBR=rmcilroy@chromium.org
TEST=cctest/test-bytecode-generator
NOTREECHECKS=true
NOTRY=true

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

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

This models function local control flow through try-finally constructs
using a token dispatch mechanism. All paths through the finally block
are assigned a token, at the end of the finally block a switch construct
dispatches according to this token.

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

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

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

Break and continue operations need to pop the context chain to the
correct context before jumping to the target.

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

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

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

This fixes the broken return address when the exception handler within
interpreted bytecode is being entered via stack unwinding. The address
in question will never actually be taken, but our stack walker uses this
address to determine whether a frame is interpreted.

R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryCatch
BUG=v8:4674
LOG=n

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

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

In d8, run with --runtime-call-stats and it will output the stats when d8 finishes.

In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome)

chrome --js-flags="--runtime-call-stats --allow-natives-syntax"

To get the stats in the console, just run

console.log(%GetAndResetRuntimeCallStats());

To output stats every second:

setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000)

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

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

When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.

Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.

This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.

BUG=v8:4267
LOG=Y

Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}

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

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

We already had hand-written optimized code for %_ToName in fullcodegen,
but the optimizing compilers always went to the runtime for %_ToName,
which is pretty bad for many of our builtins. So this CL moves the
existing native code to a ToNameStub (similar to the existing
ToStringStub), and uses the ToNameStub consistently in all compilers to
actually implement %_ToName.

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

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

Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1612413003/ )

Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!

Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > 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
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}

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

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

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

Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )

Reason for revert:
the deopt issues have been taken care of by benedikt

Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > 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
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}

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

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

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

NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

The internal index used to implement for-in can never leave the
valid smi range, so there's no need to actually check for overflow
in Crankshaft. In fact the overflow only triggered a false alert
in the deopt fuzzer.

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

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

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

This simplifies correlating offsets with the output from
--print-opt-code, which outputs offsets in decimal.

We keep the hex output since branch instructions in the perf dump use
hex labels. We just include the decimal offset along with the hex offset.

BUG=

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

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

Revert "Revert of [turbofan] optimize spills in defered blocks (patchset #3 id:240001 of https://codereview.chromium.org/1551013002/ )"

This reverts commit 7f62e122.

The regressions reported in the bug below appear to be bogus, and
caused by chromium:579503

BUG=chromium:579900
LOG=N

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

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

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

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

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

Show tick count, besides the percentage spent on an
instruction. Aids perf investigations where we deal with
stalls, for example. Percentage-wise, the execution appears
distributed similarly, but the regression becomes more
apparent in the tick counts.

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

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

Rolling v8/buildtools to cf8c4332f5c9d0da4b4782d7f0122df74a16819b

Rolling v8/tools/clang to e47364ad9fb37e8255a7a5cdf7891781b3f8256e

Rolling v8/tools/swarming_client to 0b908f18767c8304dc089454bc1c91755d21f1f5

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

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

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

BUG=v8:4663
LOG=N
TBR=hpayer@chromium.org
R=ljharb@gmail.com, rossberg@chromium.org, adamk@chromium.org

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

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

Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ )

Reason for revert:
The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio

Original issue's description:
> [profiler] Implement POC Sampling Heap Profiler
>
> This implements a proof-of-concept sampling based heap profiler inspired by
> tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
>
> The basic idea is the sample allocations using a randomized Poisson process. At
> any point in time we can cheaply request the set of live sample objects that
> should be a representative sample of heap. Samples include stack-traces from the
> allocation sites, making this an effective tool for memory leak debugging.
>
> Unlike AllocationTracking, this is intended to be cheap and usable online in
> production.
>
> The proof-of-concept is only sampling new-space allocations at this point.
> Support for sampling paged space and native allocations is anticipated in the
> future.
>
> [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
> [2] http://blog.golang.org/profiling-go-programs
>
> Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262
> Cr-Commit-Position: refs/heads/master@{#33448}

TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,yangguo@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/1615173002

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

This implements a proof-of-concept sampling based heap profiler inspired by
tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].

The basic idea is the sample allocations using a randomized Poisson process. At
any point in time we can cheaply request the set of live sample objects that
should be a representative sample of heap. Samples include stack-traces from the
allocation sites, making this an effective tool for memory leak debugging.

Unlike AllocationTracking, this is intended to be cheap and usable online in
production.

The proof-of-concept is only sampling new-space allocations at this point.
Support for sampling paged space and native allocations is anticipated in the
future.

[1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[2] http://blog.golang.org/profiling-go-programs

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

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

Port f48bf12f

Original commit message:
    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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:3650
LOG=n

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

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

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

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

BUG=v8:4696
LOG=N
NOTRY=true
TBR=rossberg, nickie

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

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

Revert of Array length reduction should throw in strict mode if it can't delete an element. (patchset #7 id:220001 of https://codereview.chromium.org/1587073003/ )

Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077

Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}

TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267

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

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

Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )

Reason for revert:
tanks for-in significantly

Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> 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
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}

TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n

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

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

Motivated by finding a bug in a larger module, this CL adds the ability
to dump out a byte-by-byte, nested view of the decoded AST. This
byte-by-byte output uses the opcode enum to make it readable, but is
suitable for pasting into a byte[] in C or JS and thus making a regression
test.

Also fix a bug; the case of running out of registers for indirect calls.

R=ahaas@chromium.org
BUG=

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

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

ParseArguments already does the rewriting.

R=rossberg@chromium.org
BUG=

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

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