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

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

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

Account for the constant pool pointer slot during register allocation
data initialization.

R=danno@chromium.org, titzer@chromium.org, bmeurer@chromium.org, mcilroy@chromium.org,
TEST=cctest/test-run-machops/RunSpillConstantsAndParameters
BUG=

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

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

Float32x4, Int32x4, Uint32x4:
  store, store1, store2, store3

Int16x8, Int8x16, Uint16x8, Uint8x16:
  store

BUG=v8:4124
LOG=N

R=bbudge@chromium.org, littledan@chromium.org, jarin@chromium.org

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

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

BUG=chromium:524425
LOG=N

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

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

Remove CompilationInfo::MayUseThis() and replace it with what we really want to know: MustReplaceUndefinedReceiverWithGlobalProxy.

R=mstarzinger@chromium.org
BUG=

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

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

If JSON contains SyntaxError then V8 will report exception and won't report compile error.

LOG=Y
BUG=chromium:515382
R=yangguo@chromium.org,yurys@chromium.org

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

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

Related to 1318893002 - another source of regressions in
benchmarks sensitive to compile time is the splintering
logic. This change addresses some, but not all, of that. In
particular, there are still some places (figuring out if a
range has a hole right where a deferred set of blocks is)
that need another look.

BUG=chromium:1318893002
LOG=n

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

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

Port 5d975694

Original commit message:
    Adds support for parameters to the BytecodeArrayBuilder and BytecodeGenerator.
    Parameters are accessed as negative interpreter registers.

R=rmcilroy@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=v8:4280
LOG=N

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

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

BUG=chromium:524425
LOG=n

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

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

Float32x4, Int32x4, Uint32x4:
  load, load1, load2, load3

Int16x8, Int8x16, Uint16x8, Uint8x16:
  load

BUG=v8:4124
LOG=N

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

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

R=machenbach@chromium.org
BUG=chromium:511311
LOG=N

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

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

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

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

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

Port 5d875a57

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=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=v8:4376
LOG=n

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

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

BUG=

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

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

R=mstarzinger@chromium.org

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

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

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

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

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

BUG=

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

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

Port 00df60d1

Original commit message:
    Makes the following modifications to the interpreter builtins and
    InterpreterAssembler:
     - Adds an accumulator register and initializes it to undefined()
     - Adds a register file pointer register and use it instead of FramePointer to
       access registers
     - Modifies builtin to support functions with 0 regiters in the register file
     - Modifies builtin to Call rather than TailCall to first bytecode handler.

R=rmcilroy@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=v8:4280
LOG=N

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

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

Port 7fb31bdb

Original commit message:
    The simulator uses a separate JS stack, exhaustion of the C stack
    however is not caught by JS limit checks. This change now lowers the
    limit of the JS stack accordingly on function calls.

R=mstarzinger@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=chromium:522380
LOG=n

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

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

R=hpayer@chromium.org
BUG=v8:1490
LOG=n

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

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

BUG=chromium:525372
LOG=n

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

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

- 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=

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

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

R=bmeurer@chromium.org

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

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

This makes it clear that only components within the "heap" directory
should be friends with the Heap class. The two notable exceptions are
Factory and Isolate which represent external interfaces into the heap.

R=mlippautz@chromium.org

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

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

The CompactionSpace is temporarily used during compaction to hold migrated
objects. The payload is merged back into the corresponding space after
compaction.

Note the this is not the complete implementation and it is currently only used in a test.

BUG=chromium:524425
LOG=N

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

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

BUG=v8:4280
LOG=N
TBR=mstarzinger@chromium.org

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

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

It has become obsolete since we do the name lookup at compile time.

R=bmeurer@chromium.org

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

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

Adds a (currently unused) constant_pool() field to BytecodeArray objects.
This field points to a FixedArray object which will be used to hold constants.

The BytecodeArray is now a mixed values object type, with the
kConstantPoolOffset object holding a tagged pointer, but the remainder of the
object holding raw bytes (which could look like tagged pointers but are not).
Modify the BytecodeArray GC visitors to deal with this and test that the
field is migrated properly when evacuated.

BUG=v8:4280
LOG=N

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

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

Adds support for parameters to the BytecodeArrayBuilder and BytecodeGenerator.
Parameters are accessed as negative interpreter registers.

BUG=v8:4280
LOG=N

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

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

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

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

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

When vector based stores are on, we don't need to do this anymore.

BUG=

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

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

A few benchmarks, e.g. Massive/SQLite, turn out to be
sensitive to compile time. Upon analysis, splinter merging
and then splinter creation (splitting) appear to be the main
contributors to such regressions. This change tackles main
sources of regression in Merging. Profiling SQLite shows,
after this change, Merging as noise (down from main C++
contributor of samples)

BUG=chromium:1318893002
LOG=n

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

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

While the intention is to eventually do away with
FLAG_turbo_loop_stackcheck and FLAG_turbo_preprocess_range,
they are useful for the interim we are still testing and
benchmarking the feature.

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

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

The zone type cache would be handy inside the asm.js typer.
Pulling it out into a seperate inlinable header to allow sharing.

BUG=https://code.google.com/p/v8/issues/detail?id=4203
TEST=None
R=andreas@chromium.org,titzer@chromium.org
LOG=N

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

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

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}