The higher word (bits 32 - 63) of FPU register is set on zero before
storing result.

TEST=cctest/test-macro-assembler-mips64/Cvt_s_uw_Trunc_uw_s
BUG=

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

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

Using std::sort on a FixedArray with HeapNumbers is not very GC friendly.
Adding a separate step to properly record possible HeapNumbers.

BUG=chromium:594954
LOG=N

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

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

The trigger point in question is by now obsolete. The optimized compile
job will itself ensure that deoptimization support is present on the
incoming SharedFunctionInfo, this will make sure to produce baseline
code when necessary. The ScopeInfo is also installed at that point in
time.

R=yangguo@chromium.org

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

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

Adjust the status file after https://codereview.chromium.org/1784343004

Also removed the tests that are not failing anymore on big-endian.

BUG=

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

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

This changes the compilation pipeline so that SharedFunctionInfo objects
are always allocated before the various compilers are invoked. It is a
preparation towards having that object available during compile time and
hence reducing the dependency on FunctionLiteral and the need to copy a
lot of the information into the CompilationInfo.

Optimizing compilers already assume the SharedFunctionInfo is present
and the baseline compilers have other heap accesses sprinkled throughout
the compilation process. Duplicating statically available information
from the SharedFunctionInfo within the CompilationInfo has no benefit.

R=yangguo@chromium.org

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

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

Port 515105a7

Exact simulation of bovc and bnvc instructions.

BUG=

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

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

We need one message in case the function is not an object, and
another if it was an object but not callable.

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

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

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

BUG=chromium:568949
LOG=n
TBR=kjellander@chromium.org, tandrii@chromium.org
NOTRY=true

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

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

R=yangguo@chromium.org

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

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

  port 2aa070be (r34863)

  original commit message:
  Repair this to match what the runtime correctly does, by first checking if the
  function is a constructor before we access the prototype.

BUG=

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

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

  port 992ae64d (r34866)

  original commit message:
  This new intrinsic is used by the desugared ES6 instanceof implementation for
  the cases when the F[@@hasInstance] property is null or undefined.

BUG=

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

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

It was never being set to false in production (though it was in test-parsing.cc,
due to that test having its own flag-setting logic).

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

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

Revert of [heap] Enable black allocation. (patchset #1 id:1 of https://codereview.chromium.org/1809983002/ )

Reason for revert:
Continues to cause flaky GPU test failures on Chromium waterfall.
See details at http://crbug.com/595092#c22

Original issue's description:
> [heap] Enable black allocation.
>
> BUG=
>
> Committed: https://crrev.com/447b1156d3bb4aa693175b74780104329ccd41ea
> Cr-Commit-Position: refs/heads/master@{#34847}

TBR=mlippautz@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:595092

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

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

This patch fixes two bugs in Array.prototype.concat in conjunction with
subclassing Arrays:
- Create a new property rather than calling Set when adding elements to
  the output array. This means setters are not called.
- If there is an exception thrown from DefineProperty, propagate it
  outwards properly, rather than swallowing it. This can occur, e.g., with
  a Proxy as the new output array.

R=adamk
LOG=Y
BUG=chromium:595319

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

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

Previously, when a property was non-configurable or the object was
non-extensible, CreateDataProperty might just return false rather than
throwing, even if should_throw was on. This patch fixes that issue.

Tested by running the patch at https://codereview.chromium.org/1814933002
on top of this code and observing the tests to see an exception thrown.

R=adamk
BUG=chromium:595319
LOG=Y

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

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

This reverts commit 4857110c.

This change was flushing out another issue which is fixed in
  https://codereview.chromium.org/1783283003/

BUG=v8:2999
LOG=N

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

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

Port 992ae64d

Original commit message:
    This new intrinsic is used by the desugared ES6 instanceof implementation for
    the cases when the F[@@hasInstance] property is null or undefined.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port 2aa070be

Original commit message:
    Repair this to match what the runtime correctly does, by first checking if the
    function is a constructor before we access the prototype.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=

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

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

Port 992ae64d

Original commit message:
    This new intrinsic is used by the desugared ES6 instanceof implementation for
    the cases when the F[@@hasInstance] property is null or undefined.

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

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

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

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

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

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

Port 2aa070be

Original commit message:
    Repair this to match what the runtime correctly does, by first checking if the
    function is a constructor before we access the prototype.

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

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

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

BUG=595259
LOG=N

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

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

Functions with builtin ids can be compiled with Ignition, so it is no longer
an option to overlap the bytecode_array field with the builtin id on
the SharedFunctionInfo object. Instead overlap it with the
inferred_name, which is only used for debug and so shouldn't be required
for functions with builtin ids. This result in the inferred_name field
being renamed to function_identifier, and adding typed accessors for
inferred_name and builtin_function_id.

This is required to build the snapshot with --no-lazy.

BUG=v8:4280
LOG=N

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

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

This new intrinsic is used by the desugared ES6 instanceof implementation for
the cases when the F[@@hasInstance] property is null or undefined.

R=mstarzinger@chromium.org

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

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

    Port 33c08596

    Original commit message:
        Int64Sub is lowered to a new turbofan operator, Int32SubPair. The new
        operator takes 4 inputs an generates 2 outputs. The inputs are the low
        word of the left input, high word of the left input, the low word of the
        right input, and high word of the right input. The ouputs are the low
        and high word of the result of the subtraction.

        The implementation is very similar to the implementation of Int64Add.

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

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

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

R=mstarzinger@chromium.org
TBR=rossberg
BUG=

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

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

Repair this to match what the runtime correctly does, by first checking if the
function is a constructor before we access the prototype.

R=verwaest@chromium.org
BUG=

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

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

Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions for the use of a memory operand are met.

This CL makes it possible to load only one of them into a register and address the other as a memory operand.

Meanwhile, comparisons between Uint8 values in the string relational comparison stubs are done with Uint32LessThan (previously we were always zero-extending the byte to a 32-bit value, so signed comparison was alright).

Found that Assembler::arithmetic_op_8(byte, Register, const Operand&) wasn't taking the Operand's rex_ field into account, so I fixed that too.

BUG=

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

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

BUG=chromium:524425
LOG=N

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

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

Port 879d254d

Original commit message:
Landing this again, excluding arm as it fail and arm64
out of caution that other wasm arm64 tests are also disabled.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm
LOG=N

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

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

Immortal immovable roots must be allocated on the first page of the space.
If serializing the root list exceeds the first page, immortal immovable root
objects might end up outside of the first page. That could cause missing
write barriers.

We now iterate the root list twice. The first time we only serialize immortal
immovable root objects. The second time we serialize the rest.

R=mstarzinger@chromium.org

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

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

The new location allows to add an external reference without requiring
an lgtm from a snapshot/ owner.

R=yangguo@chromium.org

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

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

GCC on S390 31-bit treats size_t as 'long unsigned int', which
is incompatible with %d format specifier that expects an 'int'.
Introduce a new V8 SIZET PREFIX to use %zd instead.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,yangguo@chromium.org
BUG=

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

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

HandleScopes in for-loops are rather expensive and pose a significant overhead
to some builtin/runtime-functions. The FOR_WITH_HANDLE_SCOPE macro is used to
only create a new HandleScope every 1024th iteration.

BUG=

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

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

The way desugared instanceof called OrdinaryHasInstance if the lookup of
@@hasInstance failed was incorrect.

BUG=v8:4774
LOG=N

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

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

R=titzer@chromium.org

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

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

Before this CL, free memory (FreeSpace) has been managed through a global free
list that contains single-linked lists of FreeSpace nodes for each size class.

We move away from this approach to a global two-level doubly-linked list that
refers to singly-linked lists of FreeSpace nodes on the corresponding pages.
This way we can refill on a page-level granularity. Furthermore, it also enables
constant-time eviction of pages from the free list.

BUG=chromium:524425
LOG=N

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

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

(The goal is to have CodeStubAssembler be the sole assembler-like user of
the TF compiler pipeline; with RMA being a private implementation detail
and FAA being a client.)

BUG=chromium:508898
LOG=Y

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

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

* New and old space pages have the same allocatable memory size
* Enforce declaration order in NewSpacePage

BUG=chromium:581412
LOG=N

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

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

NOTRY=true
NOTREECHECKS=true
TBR=machenbach@chromium.org

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

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