R=jochen@chromium.org

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

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

Rename ZoneTypeCache to TypeCache and use a single shared (immutable)
instance consistently to cache the most commonly used types. Also serves
as a chokepoint for defining those types, so we don't repeat the
definition (and possible bugs) in various places.

R=jarin@chromium.org

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

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

R=jochen@chromium.org

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

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

TEST=cctest/test-gap-resolver/FuzzResolver,unittests/MoveOptimizerTest.RemovesRedundantExplicit
BUG=

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

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

BUG=

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

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

[heap] Convert overapproximate weak closure phase into finalize incremental marking phase and revisit the root set there.

BUG=chromium:548562
LOG=n

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

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

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

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

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

  In order to resolve the sqrt precision issue described in https://codereview.chromium.org/1425763002/.
  we change the implementation of CreateSqrtFunction() implementation of X87 so that the optimize compiler
  and full-compiler implementation are unified.

R=weiliang.lin@intel.com
BUG=

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

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

R=jkummerow@chromium.org
BUG=v8:4450
LOG=N

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

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

Only mark the last fallthrough control as deferred, otherwise the
splintering will ruin the code generation for the (maybe likely)
polymorphic cases.

Drive-by-fix: Reduce overall code duplication between JSLoadNamed
and JSStoreNamed specialization.

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

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

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

R=bmeurer@chromium.org

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

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

Float(32|64)Min:
  // (a < b) ? a : b
  fcmp da, db
  fcsel dd, da, db, lo

Float(32|64)Max:
  // (b < a) ? a : b
  fcmp db, da
  fcsel dd, da, db, lo

BUG=

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

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

Adds support for delete operator, it's implementation and tests.

Adds tests for the following unary operators
  -BitwiseNot
  -Add
  -Sub

BUG=v8:4280
LOG=N

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

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

This lowers JSCreateArguments nodes within inline (i.e. non-outermost)
frames that create "mapped arguments objects" to inline allocations.

The arguments count as well as each value is statically known and can be
directly stored into the arguments object. Note that the object is still
context-dependent and the map is loaded from the current context. The
object size is not taken into account for now, we might want to limit it
later though to keep code size bounded.

R=jarin@chromium.org

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

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

Typed lowering can lower JSConvertReceiver either based on the operator
hints or the (statically) known receiver type.

R=jarin@chromium.org
BUG=chromium:548557, v8:4493, v8:4470
LOG=n

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

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

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

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

BUG=

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

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

Rolling v8/third_party/android_tools to 54492f99c84cab0826a8e656efeb33a1b1bf5a04

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

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

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

When == is invoked on a Symbol or SIMD vector and an object, the object should
be converted to a primitive with ToPrimitive and then compared again. This means,
for example, that for a Symbol or SIMD vector s, s == Object(s). This patch makes
that change in the implementation of ==. Only the runtime function needed to be
changed, as the code stubs and compiler specializations don't operate on Symbols
or SIMD vectors, and on these types, a fallback to the runtime function is always
used.

BUG=v8:3593
LOG=Y
R=adamk

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

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

This fixes a missing SSA-renaming of the callee value used in the frame
state of a call node. An OSR-entry within do-expressions contained in
one of the argument expression can trigger that renaming.

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

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

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

BUG=chromium:535160
LOG=n

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

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

Scavenger should not attempt to visit ArrayBuffer's storage, it is a
user-supplied pointer that may have any alignment. Visiting it, may
result in a crash.

BUG=
R=jochen

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

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

Reland of Check that array length stays a safe integer in Array.prototype.push (patchset #1 id:1 of https://codereview.chromium.org/1418093007/ )

Reason for revert:
The test failure was unrelated; relanding.

Original issue's description:
> Revert of Check that array length stays a safe integer in Array.prototype.push (patchset #7 id:120001 of https://codereview.chromium.org/1428483002/ )
>
> Reason for revert:
> Caused for-in-opt test to fail
>
> Original issue's description:
> > Check that array length stays a safe integer in Array.prototype.push
> >
> > This patch adds a check in Array.prototype.push to assert that the new
> > length does not become greater than 2**53-1. Such a length would be
> > dangerous because integer arithmetic becomes imprecise after the
> > boundary. The check is also required by a test262 test.
> >
> > R=adamk
> > LOG=Y
> > BUG=v8:3087
> >
> > Committed: https://crrev.com/e68adf4548dd101dc08fcbff14444152fb1b7fe7
> > Cr-Commit-Position: refs/heads/master@{#31588}
>
> TBR=adamk@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:3087
>
> Committed: https://crrev.com/78abedb94431a233842fcb2f7a910805a05bed09
> Cr-Commit-Position: refs/heads/master@{#31590}

TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3087

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

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

Previously ChangeLowering would always box float64 values when going to
tagged representation, but that introduces a lot of deoptimizer loops
and polymorphism into TurboFan, which is unfortunate and unnecessary.

This adds some logic to ChangeFloat64ToTagged to try harder to create a
Smi when going from Float64 to Tagged, instead of always allocating a
HeapNumber.  This might need some additional tweaking, but at least it
makes it possible to start comparing TurboFan and Crankshaft for some
regular JavaScript.

R=jarin@chromium.org

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

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

BUG=chromium:535160
LOG=n

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

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

Full-codegen prepared for the bailout in the wrong place, causing side
effects to be replayed when they shouldn't. Crankshaft and Turbofan are
in agreement about where the deopt should jump to.

TEST=mjsunit/for-in-opt
R=jarin@chromium.org
BUG=v8:4381
LOG=y

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

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

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

kExpectedPages should be ceil(kNumObjects / kNumObjectsPerPage)

R=mlippautz@chromium.org, hpayer@chromium.org
BUG=

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

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

BUG=v8:4280
LOG=N

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

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

Up until now, if one wanted to specify an explicit stack location                                                                                                                                                                                                or register as an operand for an instruction, it had to also be
explicitly associated with a virtual register as a so-called
FixedRegister or FixedStackSlot.

For the implementation of tail calls, the plan is to use the gap
resolver needs to shuffle stack locations from the caller to the
tail-called callee. In order to do this, it must be possible to
explicitly address operand locations on the stack that are not
associated with virtual registers.

This CL introduces ExplictOperands, which can specify a specific
register or stack location that is not associated with virtual
register. This will allow tail calls to specify the target
locations for the necessary stack moves in the gap for the tail
call without the core register allocation having to know about
the target of the stack moves at all.

In the process this CL:
* creates a new Operand kind, ExplicitOperand, with which
  instructions can specify register and stack slots without an
  associated virtual register.
* creates a LocationOperand class from which AllocatedOperand and
  ExplicitOperand are derived and provides a common interface to
  get Register, DoubleRegister and spill slot information.
* removes RegisterOperand, DoubleRegisterOperand,
  StackSlotOperand and DoubleStackSlotOperand, they are subsumed
  by LocationOperand.
* addresses a cleanup TODO in AllocatedOperand to reduce the
  redundancy of AllocatedOperand::Kind by using machine_type() to
  determine if an operand corresponds to a general purpose or
  double register.

BUG=v8:4076
LOG=n

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

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

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

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

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

BUG=chromium:490559
LOG=NO

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

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

Adds a scavenge GC pass that collects unmodified references instead of
processing object groups. This mode can be controlled by setting
FLAG_scavenge_reclaim_unmodified_objects. By default this is turned off.
Also, modified a test case to suit the handle the new GC pass.

BUG=v8:4421
LOG=N

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

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

This introduces a JSConvertReceiver operator to model the implicit
conversion of receiver values for sloppy callees. It is used by the
JSInliner for now, but can also be used to model direction function
calls that bypass call stubs.

Also note that a hint is passed to said operator whenever the source
structure constrains the receiver value type. This hint allows for
optimizations in the lowering of the operator.

The underlying specification in ES6, section 9.2.1.2 is the basis for
this implementation.

R=bmeurer@chromium.org
TEST=mjsunit/compiler/receiver-conversion
BUG=v8:4493, v8:4470
LOG=n

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

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

BUG=

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

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

Change CompareNilIC to return true/false instead of 1/0, and use the
CompareNilICStub in TurboFan for abstract equality with null/undefined.
This way we don't always run into the %Equals runtime fallback when
comparing objects with null/undefined.

R=jarin@chromium.org

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

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

R=jochen
BUG=

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

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

Currently we still (mis)used some machine operators in typed lowering
(namely Word32Or, Word32Xor and Word32And). But these operators are
"polymorphic" in the signedness of their inputs and output, hence the
representation selection (and thereby simplified lowering) was unable to
figure out whether a bitwise operation that was seen would produce an
unsigned or a signed result. If such nodes also have frame state uses,
the only safe choice was float64, which was not only a lot less ideal,
but also the main cause of the for-in related deoptimizer loops.

Adding dedicated NumberBitwiseOr, NumberBitwiseAnd and NumberBitwiseXor
simplified operators not only gives us precise (and correct) typing for
the bitwise operations, but also allows us to actually verify the graph
properly after typed lowering.

Drive-by-fix: Remove the double-to-smi magic from the Deoptimizer, which
is responsible for various deopt-loops in TurboFan, and is no longer
needed with the addition of the NumberBitwise operators.

R=jarin@chromium.org

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

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

With ES6 21.2.5.8, step 13, we no longer have to keep up the illusion
that matching and calling replace function is interleaved. This is
observable through unspec'ed static properties such as RegExp.$1.

Last match info not working yet.

R=littledan@chromium.org

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

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