port 5d875a57 (r30342).

original commit message:

    The previous hack with HInstanceOfKnownGlobal was not only slower,
    but also very brittle and required a lot of weird hacks to support it. And
    what's even more important it wasn't even correct (because a map check
    on the lhs is never enough for instanceof).

    The new implementation provides a sane runtime implementation
    for InstanceOf plus a fast case in the InstanceOfStub, combined with
    a proper specialization in the case of a known global in CrankShaft,
    which does only the prototype chain walk (coupled with a code
    dependency on the known global).

    As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
    implementation.

R=weiliang.lin@intel.com
BUG=

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

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

This fixes broken dynamic hole-checks for the temporal dead zone of
non-initializing assignments to {let} and {const} declared variables.
Also note that this exemplifies a case where the dynamic check for such
assignments to {let} declared variables can no longer be elided as the
comment suggested.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4388
BUG=v8:4388
LOG=n

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

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

BUG=chromium:523213
LOG=N

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

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

BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

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

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

R=mlippautz@chromium.org

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

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

BUG=v8:4141
LOG=n
R=mlippautz@chromium.org

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

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

A TopLevelLiveRange is the live range of a virtual register. Through
register allocation, it may end up being split in a succession of child
live ranges, where data flow is handled through moves from
predecessor to successor child.

Today, the concepts of "top level" and "child" live ranges are conflated
under the LiveRange class. However, a good few APIs pertain solely
to TopLevelLiveRanges. This was communicated through comments or
DCHECKs - but this makes for poor code comprehensibility and maintainability.

For example, the worklist of the register allocator (live_ranges()) needs
to only contain TopLevelLiveRanges; spill range concerns are associated
only with the top range; phi-ness; certain phases in the allocation pipeline;
APIs on LiveRange used for initial construction - before splitting;
splintering - these are all responsibilities associated to TopLevelLiveRanges,
and not child live ranges.

This change separates the concepts.

An effect of this change is that child live range allocation need not involve
RegisterAllocationData. That's "a good thing" (lower coupling), but it has
the side-effect of not having a good way to construct unique identifiers for
child live ranges, relative to a given InstructionSequence.

LiveRange Id are used primarily for tracing/output-ing, and debugging.

I propose a 2-component identifier: a virtual register (vreg) number,
uniquely identifying TopLevelLiveRanges; and a relative identifier, which
uniquely identifies children of a given TopLevelLiveRange. "0" is reserved
for the TopLevel range. The relative identifier does not necessarily
indicate order in the child chain, which is no worse than the current state
of affairs.

I believe this change should make it easier to understand a trace output
(because the virtual register number is readily available). I plan to formalize
with a small structure the notion of live range id, and consolidate tracing
around that, as part of a separate CL. (there are seemingly disparate ways
to trace - printf or stream-based APIs - so this seems like an opportune
change to consolidate that)

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

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

Rolling v8/third_party/icu to 6b3ce817f8e828c3b7a577d2395f0882eb56ef18

TBR=machenbach@chromium.org

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

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

   For X87 platform, it has the same general register as ia32 and it will spill the
   context to the stack too.

port bfdc22d7 (r29325).

original commit message:

    Passes the current context to bytecode interpreter handlers. This is held in the
    context register on all architectures except for ia32 where there are too few
    registers and it is instead spilled to the stack.

    Also changes Load/StoreRegister to use kMachAnyTagged representation since they
    should only ever hold tagged values.

BUG=

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

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

Visit AST Property nodes as expressions in AstExpressionVisitor.
Visit Yield and Throw as they are expressions too.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-ast-expression-visitor, test-typing-reset
R=rossberg@chromium.org,titzer@chromium.org
LOG=N

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

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

Eliminates duplicate var's and assignments.

LOG=N
BUG=v8:4124

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

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

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

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

The lack of marking this dependency led to a ClusterFuzz crash when
sloppy-function was on but not sloppy. This case does not make sense.

R=adamk
LOG=N
BUG=chromium:520891

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

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

R=littledan@chromium.org
BUG=

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

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

Make ObjectLiteral::is_simple() false for literals containing computed
property names, which causes IsCompileTimeValue() to return false and
thus force code to be generated for setting up such properties. This
mirrors the handling of '__proto__' in literals.

BUG=v8:4387
LOG=y

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

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

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

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

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

These were missed by the previous tests,
uncovered in another context.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-ast-expression-visitor
R=rossberg@chromium.org,titzer@chromium.org
LOG=N

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

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

BUG=524425
LOG=n

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

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

R=mlippautz@chromium.org

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

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

This change encompasses what is necessary to enable stack checks in loops without suffering large regressions.

Primarily, it consists of a new mechanism for dealing with deferred blocks by "splintering", rather than splitting, inside deferred blocks.

My initial change was splitting along deferred block boundaries, but the regression introduced by stackchecks wasn't resolved conclusively. After investigation, it appears that just splitting ranges along cold block boundaries leads to a greater opportunity for moves on the hot path, hence the suboptimal outcome.

The alternative "splinters" ranges rather than splitting them. While splitting creates 2 ranges and links them (parent-child), in contrast, splintering creates a new independent range with no parent-child relation to the original. The original range appears as if it has a liveness hole in the place of the splintered one. All thus obtained ranges are then register allocated with no change to the register allocator.

The splinters (cold blocks) do not conflict with the hot path ranges, by construction. The hot path ones have less pressure to split, because we remove a source of conflicts. After allocation, we merge the splinters back to their original ranges and continue the pipeline. We leverage the previous changes made for deferred blocks (determining where to spill, for example).

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

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

BUG=

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

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

R=mlippautz@chromium.org

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

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

BUG=v8:4280
LOG=N

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

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

Adds Uint32x4, Uint16x8, and Uint8x16 types.
Adds all functions in the current spec, except for loads and stores.

LOG=Y
BUG=v8:4124

Committed: https://crrev.com/4be6d37fd1ad0a6e0ea37da8863ae5169c2b89ba
Cr-Commit-Position: refs/heads/master@{#30322}

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

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

Adds implementations and tests for the following bytecodes:
  - Add
  - Sub
  - Mul
  - Div
  - Mod

Also adds the Mod bytecode and adds support to BytecodeGenerator and
BytecodeArrayBuilder to enable it's use.

The current bytecodes always call through to the JS builtins. This also adds
LoadObjectField and CallJSBuiltin operators to the InterpreterAssembler.

BUG=v8:4280
LOG=N

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

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

Revert of Moving ArraySplice Builtin to ElementsAccessor (patchset #8 id:140001 of https://codereview.chromium.org/1293683005/ )

Reason for revert:
Fails layout tests: http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2032/builds/1450

Original issue's description:
> - remove the Backing-Store specific code from builtins.cc and put it in elements.cc.
> - adding tests to improve coverage of the splice method
>
> BUG=
>
> Committed: https://crrev.com/8533d4b5433d3a9e9fb1015f206997bd6d869fe3
> Cr-Commit-Position: refs/heads/master@{#30269}
>
> Committed: https://crrev.com/07a4a6cb8e2ab940b28a7151a925c796da023524
> Cr-Commit-Position: refs/heads/master@{#30326}

TBR=mvstanton@chromium.org,cbruni@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

Revert of Array.prototype.unshift builtin improvements (patchset #3 id:40001 of https://codereview.chromium.org/1311343002/ )

Reason for revert:
https://codereview.chromium.org/1315823004/

Original issue's description:
> Array.prototype.unshift builtin improvements
>
> Moving unshift to ElementAccessor and increasing the range of arguments
> handled directly in C++, namely directly supporting FastDoubleElementsKind.
> This should yield a factor 19 speedup for unshift on fast double arrays.
>
> BUG=
>
> Committed: https://crrev.com/bf6764e6c1197e50ae148755488307a423b1d9b4
> Cr-Commit-Position: refs/heads/master@{#30347}

TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

Moves the GCCallbackflags where they belong, i.e., {Heap}, and gets rid of
IncrementalMarking::Start() callsites.

BUG=

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

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

The PLACEHOLDER code kind is used when compiling a code object that has
direct calls to other code objects, but those other code objects do not
yet exist because they have not yet been compiled. It serves as a
placeholder to break the cycle, e.g. in WASM.

R=yangguo@chromium.org
BUG=

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

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

Moving unshift to ElementAccessor and increasing the range of arguments
handled directly in C++, namely directly supporting FastDoubleElementsKind.
This should yield a factor 19 speedup for unshift on fast double arrays.

BUG=

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

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

...in canary.

This reverts commit c75af232.

R=hablich@chromium.org
BUG=

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

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

Followup to https://codereview.chromium.org/1288683005

BUG=chromium:521946
LOG=N

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

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

BUG=

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

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

The HUnaryMathOperation cannot be eliminated in general, because the
spec requires a ToNumber conversion on the input, which is observable
of course.

BUG=v8:4389
LOG=y

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

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

The previous hack with HInstanceOfKnownGlobal was not only slower,
but also very brittle and required a lot of weird hacks to support it. And
what's even more important it wasn't even correct (because a map check
on the lhs is never enough for instanceof).

The new implementation provides a sane runtime implementation
for InstanceOf plus a fast case in the InstanceOfStub, combined with
a proper specialization in the case of a known global in CrankShaft,
which does only the prototype chain walk (coupled with a code
dependency on the known global).

As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
implementation.

BUG=v8:4376
LOG=y

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

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

Adds the flag to the test configuration so we aren't just testing the
polyfill.
Fixes some number conversion in native fromFloat32x4 function that now
fails.

LOG=N
BUG=v8:4124

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

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

The ES2015 specification for switch statements 13.12.11 specifies that
they get their own lexical scope. This patch introduces such a scope
through a complex desugaring in terms of blocks, done so that Crankshaft
does not have to be updated to support multiple constructs providing
scopes.

Recommitting this patch after a bug fix in Crankshaft to allow a
desugaring with certain elements missing a source location:
https://codereview.chromium.org/1313443002

BUG=v8:4377
LOG=Y
R=adamk

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

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

Intent to ship: https://groups.google.com/d/msg/v8-users/-a8_8cb6FRI/trjyB5bACQAJ

BUG=v8:3575
R=adamk@chromium.org, rossberg@chromium.org
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

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

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

R=adamk@chromium.org, wingo@igalia.com
BUG=v8:811
LOG=N

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

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

This patch translates RelocInfo::kNoPosition to SourcePosition::Unknown()
in constructing the Hydrogen graph from the parser's output. The translation
is done to increase the flexibility of the parser to desugar more things
that don't have natural locations.

R=bmeurer@chromium.org
BUG=v8:4377
LOG=N

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

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