R=jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=

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

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

Port cbbaf9ea

Note that the above commit breaks embedded constant pools and will need to
be revised in a future CL.

Original commit message:
    Previously, it was not possible to specify StackSlotOperands for all
    slots in both the caller and callee stacks. Specifically, the region
    of the callee's stack including the saved return address, frame
    pointer, function pointer and context pointer could not be addressed
    by the register allocator/gap resolver.

    In preparation for better tail call support, which will use the gap
    resolver to reconcile outgoing parameters, this change makes it
    possible to address all slots on the stack, because slots in the
    previously inaccessible dead zone may become parameter slots for
    outgoing tail calls. All caller stack slots are accessible as they
    were before, with slot -1 corresponding to the last stack
    parameter. Stack slot indices >= 0 access the callee stack, with slot
    0 corresponding to the callee's saved return address, 1 corresponding
    to the saved frame pointer, 2 corresponding to the current function
    context, 3 corresponding to the frame marker/JSFunction, and slots 4
    and above corresponding to spill slots.

    The following changes were specifically     needed:

    * Frame     has been changed to explicitly manage three areas of the
      callee frame, the fixed header, the spill slot area, and the
      callee-saved register area.
    * Conversions from stack slot indices to fp offsets all now go through
      a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
    * The generation of deoptimization translation tables has been changed
      to support the new stack slot indexing scheme. Crankshaft, which
      doesn't support the new slot numbering in its register allocator,
      must adapt the indexes when creating translation tables.
    * Callee-saved parameters are now kept below spill slots, not above,
      to support saving only the optimal set of used registers, which is
      only known after register allocation is finished and spill slots
      have been allocated.

R=danno@chromium.org, titzer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=

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

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

R=titzer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=

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

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

Port fe432e1a

R=mvstanton@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=

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

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

Port cd351559

R=mvstanton@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=

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

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

Port f4c079d4

Original commit message:
    There's no need to have one InstanceType per SIMD primitive type (this
    will not scale long-term).  Also reduce the amount of code duplication
    and make it more robust wrt adding new SIMD types.

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

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

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

R=yangguo@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=

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

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

Port b62dbf1e

Original commit message:
    Support for undetectable strings was officially dropped in
    https://codereview.chromium.org/916753002, but the compilers
    weren't fixed properly.

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

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

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

R=yangguo@chromium.org

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

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

TC39 agreed to disallow "use strict" directives in function body when
non-simple parameter lists are used.

This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/
with some refactorings removed for now.

Still TODO: there is a lot of duplication between the is_simple field of
FormalParametersBase and the NonSimpleParameter property ExpressionClassifier
keeps track of. It should be possible to remove the former with a minor
refactoring of arrow function parsing. This will be attempted in a follow-up CL.

BUG=
LOG=N

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

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

R=rossberg@chromium.org

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

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

When encountering a "=" token in ParseAssignmentExpression, the default
parameter case is not locally distinguishable from the destructuring case.

BUG=

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

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

R=rossberg@chromium.org

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

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

R=rossberg@chromium.org

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

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

BUG=chromium:524425
LOG=n

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

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

R=cbruni@chromium.org

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

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

Thanks to André Bargull for the report.

BUG=v8:4212
LOG=N
R=rossberg@chromium.org

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

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

%_IsObject(foo) is equivalent to typeof foo === 'object' and has
exactly the same optimizations, so there's zero need for %_IsObject
in our code base.

R=mstarzinger@chromium.org

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

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

We look up %-functions in the context if not found in the runtime.

R=bmeurer@chromium.org, mstarzinger@chromium.org

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

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

For vector-based keyed store ics, we need to know the current
KeyedAccessStore mode on ic MISS, and to produce optimized code.

We can't store this mode, which can change on any MISS in the IC
without patching. Therefore, this CL makes sure that the information is
redundantly available in the handlers embedded in the IC. This way,
when --vector-stores is turned on, we'll be able to extract that
information from the vector which maintains a list of these handlers.

BUG=

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

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

R=mlippautz@chromium.org

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

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

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}