We not keep track of the histogram as we process values and do not wait until
printing the histogram. Furthermore processing the histogram is not O(n) for n
values.

BUG=

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

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

For string wrappers (JSValue instances with [[StringData]] internal
fields), we can shortcirciut the ToPrimitive if

  (a) the {input} map matches the initial map of the String function,
  (b) the {input} [[Prototype]] is the unmodified %StringPrototype% (i.e.
      no one monkey-patched toString, @@toPrimitive or valueOf), and
  (c) the %ObjectPrototype% (i.e. the [[Prototype]] of the
      %StringPrototype%) is also unmodified, that is no one sneaked a
      @@toPrimitive into the %ObjectPrototype%.

If all these assumptions hold, we can just take the [[StringData]] value
and return it.

This just repairs a regression introduced by removing the
weird (and broken) intrinsic %_IsStringWrapperSafeForDefaultValue, which
was intendend to something similar to this, although less efficient and
wrong in the presence of @@toPrimitive. Long-term we might want to move
into the direction of having a ToPrimitiveStub that can do common cases
while staying in JavaScript land (i.e. not going to C++).

R=jarin@chromium.org
BUG=chromium:532524
LOG=n

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

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

BUG=chromium:527994
LOG=n

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

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

Revert of [heap] Add more tasks for parallel compaction (patchset #11 id:200001 of https://codereview.chromium.org/1354383002/ )

Reason for revert:
[Sheriff] May have caused this new flake:
http://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/5412

Original issue's description:
> [heap] Add more tasks for parallel compaction
>
> - We now compute the number of parallel compaction tasks, depending on the
>   evacuation candidate list, the number of cores, and some hard limit.
> - Free memory is moved over to compaction tasks (up to some limit)
> - Moving over memory is done by dividing the free list of a given space up among
>   other free lists. Since this is potentially slow we limit the maximum amount
>   of moved memory.
>
> BUG=chromium:524425
> LOG=N
>
> Committed: https://crrev.com/0e842418835eea85886a06cf37052895bc8a17db
> Cr-Commit-Position: refs/heads/master@{#30886}

TBR=hpayer@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

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

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

Whenever a generalization is computed, the inputs must be checked for being cleared, and if they are, the generalization must be Type::Any.

Hopefully this fixes Chromium issue 527994 as well.

BUG=v8:4325,chromium:527994
LOG=n

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

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

- We now compute the number of parallel compaction tasks, depending on the
  evacuation candidate list, the number of cores, and some hard limit.
- Free memory is moved over to compaction tasks (up to some limit)
- Moving over memory is done by dividing the free list of a given space up among
  other free lists. Since this is potentially slow we limit the maximum amount
  of moved memory.

BUG=chromium:524425
LOG=N

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

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

NOTRY=true

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

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

R=bmeurer@chromium.org
BUG=

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

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

We somehow try to push some stuff on the stack when we detect a stack
overflow, that we don't need. Even worse we might access outside the
valid stack bounds. Since we don't need this, it's gone.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org
BUG=chromium:534881
LOG=n

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

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

FilterFiles function is defined but unused in the code.

BUG=

R=machenbach@chromium.org

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

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

This patch checks the type of the lhs operand of a floating point
comparison, and commutes the operands if it is #0.0.  It allows us to
optimize a comparison with zero, as the fcmp instruction accepts #0.0 as
rhs operand.

Code before for "0.0 < 0.123":
------------------------------
fmov d1, xzr
ldr d0, pc+96
fcmp d1, d0
b.lo #+0xc

Code after:
-----------
ldr d0, pc+92
fcmp d0, #0.0
b.gt #+0xc

Before this patch, we used unsigned condition codes for floating point
comparisons, but the unordered case was not correctly commuted.

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

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

(Original CL: https://codereview.chromium.org/1347353003/)

Unfortunately, the mips gcc gets confused by arraysize on
variadic templated arguments, so we use sizeof... instead.

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

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

This CL also renames wrongly named test for v8:4173.

BUG=v8:4121
LOG=Y

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

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

Revert of [turbofan] Checking of input counts on node creation (patchset #4 id:60001 of https://codereview.chromium.org/1347353003/ )

Reason for revert:
[Sheriff] Breaks mips cross-compile:
http://build.chromium.org/p/client.v8/builders/V8%20Mips%20-%20builder/builds/4315

Original issue's description:
> [turbofan] Checking of input counts on node creation
>
> This required fixing bunch of tests with wrong input counts.
>
> Committed: https://crrev.com/260ec46efd74c45cdc4b156d95086b7de06621ad
> Cr-Commit-Position: refs/heads/master@{#30877}

TBR=bmeurer@chromium.org,mstarzinger@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

This required fixing bunch of tests with wrong input counts.

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

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

TBR=machenbach@chromium.org

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

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

We don't need Object::IsSpecFunction anymore, since it only checks for
JSFunction and JSFunctionProxy, but what you actually want to check for
(in case of accessors) is whether the target has a [[Call]] internal
method, which is exactly what Object::IsCallable does.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=rossberg@chromium.org
BUG=v8:4413
LOG=n

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

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

Now both Execution::Call and Execution::New can deal with any
kind of target and will raise a proper exception if the target is not
callable (which is not yet spec compliant for New, as we would
have to check IsConstructor instead, which we don't have yet).

Now we no longer need to do any of these weird call/construct
delegate gymnastics in C++, and we finally have a single true
bottleneck for Call/Construct abstract operations in the code
base, with only a few special handlings left in the compilers to
optimize the JSFunction case.

R=jarin@chromium.org
BUG=v8:4430, v8:4413
LOG=n

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

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

BUG=
R=bmeurer@chromium.org

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

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

Port 1dfac69f

Original commit message:
    Introduce new builtins Construct and ConstructFunction (in line
    with the Call and CallFunction builtins that we already have) as
    proper bottleneck for Construct and [[Construct]] on JSFunctions.
    Use these builtins to support passing NewTarget from C++ to
    JavaScript land.

    Long-term we want the CallConstructStub to be used for
    gathering feedback on entry to construction chain (i.e. the
    initial new Foo), and use the Construct builtins to do the
    actual work inside the construction chain (i.e. calling into
    super and stuff).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=v8:4430
LOG=n

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

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

Port 10c5f2e8

Original commit message:
    Slow path for relational comparison of boolean primitive values
    now goes through the runtime, which made the slow path even
    slower than it already was. So in order to repair the regression,
    we just track boolean feedback for comparisons and use that
    to generate decent code in Crankshaft (not the best possible
    code, but good enough for Crankshaft; TurboFan will be able
    to do better on that).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=chromium:534200
LOG=n

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

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

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

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

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

Port e56f265f

Original commit message:
    Previously we only collected the known map for equality comparisons. But
    if we also collect it for relational comparisons, we can inline a fast
    path of ToPrimitive on the objects, which is especially interesting
    since both sides have the same map.

    For now we only inline a very limited subset of ToPrimitive in
    Crankshaft, which is when the receiver map (and its prototype chain)
    doesn't have @@toPrimitive, and both valueOf and toString are the
    default versions on the %ObjectPrototype%. In this case the relational
    comparison would reduce to a string comparison of "[object CLASS]" with
    itself and so we can reduce that to a boolean constant plus map checks
    on both left and right hand side, plus code dependencies on the
    prototype chain. This repairs the regression on box2d.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=chromium:534200
LOG=n

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

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

This adds the materialized literal count accumulated while parsing the
parameters (in the parser proper) to that accumulated by the preparser.

This should have been caught in cctest/test-parsing, but it's not covered
because the parsing tests call directly into the preparser rather than
using Parser::ParseFunctionLiteral (which fully-parses the parameters
and then calls into the preparser to skip over the function body).

Note that this further-inflates the materialized literal count for
functions with destructured arguments, since some of the counted
literals are actually binding patterns. But that's not specific to
binding patterns in formal parameters: it happens in function bodies, too.

BUG=v8:4400,v8:4407
LOG=n

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

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

Weak classes can inherit from strong ones again, a strong base class makes
instances strong.

BUG=v8:3956
LOG=N

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

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

R=rossberg
BUG=

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

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

BUG=

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

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

This reduces the pause time of weak cells processing during a full GC.

BUG=

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

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

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

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

With the IC-less global variables accesses the size of the Rotate* functions became small enough to be immediately optimized by Crankshaft which in turn tanked SunSpider/3d-cube.

BUG=chromium:531338
LOG=N

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

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

Slow path for relational comparison of boolean primitive values
now goes through the runtime, which made the slow path even
slower than it already was. So in order to repair the regression,
we just track boolean feedback for comparisons and use that
to generate decent code in Crankshaft (not the best possible
code, but good enough for Crankshaft; TurboFan will be able
to do better on that).

R=jarin@chromium.org
BUG=chromium:534200
LOG=n

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

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

Fixes a typo introduced earlier, where we compare the value to heap
number map instead of the map loaded previously.

TBR=jarin@chromium.org

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

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

Now the StringAddStub can optionally convert it's parameters to strings
(following the rules for the addition operator). This could be further
optimized once we have a ToPrimitiveStub, but it should be sufficient
for the moment.

Also removed the unused Strength parameter to the HStringAdd operator,
because string addition does not depend on language mode.

R=jarin@chromium.org
BUG=v8:4307, chromium:532524
LOG=n

Committed: https://crrev.com/d261849e53fbf8c36efae42d478271f87acff70f
Cr-Commit-Position: refs/heads/master@{#30726}

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

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

Introduce new builtins Construct and ConstructFunction (in line
with the Call and CallFunction builtins that we already have) as
proper bottleneck for Construct and [[Construct]] on JSFunctions.
Use these builtins to support passing NewTarget from C++ to
JavaScript land.

Long-term we want the CallConstructStub to be used for
gathering feedback on entry to construction chain (i.e. the
initial new Foo), and use the Construct builtins to do the
actual work inside the construction chain (i.e. calling into
super and stuff).

MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.

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

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

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

If @@toStringTag is an accessor property, we cannot assume that the result
of calling Object.prototype.toString() for objects with the same map.

R=adamk@chromium.org
BUG=chromium:534200
LOG=n

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

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

Rolling v8/build/gyp to 01528c7244837168a1c80f06ff60fa5a9793c824

Rolling v8/tools/clang to 3e04436a49a26f4bd2c6f352efcf4c7b10a6d07d

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

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

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

We need to build parts of v8 with a toolchain that might be different
from both the default (target) toolchain and the regular host toolchain,
because we need the snapshot to have the same bit-width as the target.
V8's build defines a 'snapshot_toolchain' setting for this.

It turns out that we need the value of this toolchain to be exposed
to the Chromium build because some of the test targets (in browser_tests)
depend on d8 and need to be able to built using the same toolchain.

R=brett@chromium.org, jochen@chromium.org
BUG=

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

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

Turn on some test262 tests that pass now.

R=adamk
LOG=Y
BUG=v8:4285

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

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

Previously we only collected the known map for equality comparisons. But
if we also collect it for relational comparisons, we can inline a fast
path of ToPrimitive on the objects, which is especially interesting
since both sides have the same map.

For now we only inline a very limited subset of ToPrimitive in
Crankshaft, which is when the receiver map (and its prototype chain)
doesn't have @@toPrimitive, and both valueOf and toString are the
default versions on the %ObjectPrototype%. In this case the relational
comparison would reduce to a string comparison of "[object CLASS]" with
itself and so we can reduce that to a boolean constant plus map checks
on both left and right hand side, plus code dependencies on the
prototype chain. This repairs the regression on box2d.

R=jkummerow@chromium.org
BUG=chromium:534200
LOG=n

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

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