R=mvstanton@chromium.org

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

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

This replaces the counters for use representations with
simple tracking of most-general representation seen so far.

R=bmeurer@chromium.org

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

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

Revert of Stop prepending "r" to commit hashes in merge_to_branch.py (patchset #1 id:1 of https://codereview.chromium.org/1298973007/ )

Reason for revert:
Result when using the script:

tools/release/merge_to_branch.py
  File "tools/release/merge_to_branch.py", line 108
    self["revision_list"] = ", ".join(self["full_revision_list"]))
                                                                 ^
SyntaxError: invalid syntax

Original issue's description:
> Stop prepending "r" to commit hashes in merge_to_branch.py
>
> R=machenbach@chromium.org
>
> Committed: https://crrev.com/e5dbfd06c3dab5934e846c40af2a8b7fb5cdf0d6
> Cr-Commit-Position: refs/heads/master@{#30483}

TBR=machenbach@chromium.org,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

TBR=bmeurer@chromium.org
NOTRY=true

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

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

Now that it is no longer needed, this also removes the invalid inclusion
of "object-inl.h" within the "unique.h" header file.

Note that this change still leaves 2 violations of that rule in the
code, checked with the "tools/check-inline-includes.sh" tool.

R=bmeurer@chromium.org

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

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

Revert of heap: make array buffer maps disjoint (patchset #8 id:140001 of https://codereview.chromium.org/1316873004/ )

Reason for revert:
Precautionary revert. The change is incomplete.

Original issue's description:
> heap: make array buffer maps disjoint
>
> Remove intersection from the `std::map`s representing current live
> ArrayBuffers. While being simpler to understand, it poses significant
> performance issue for the active ArrayBuffer users (like node.js).
>
> Store buffers separately, and process them together during mark-sweep phase.
>
> The results of benchmarks are:
>
> $ ./node-slow bench && ./node-fast bench
> 4997.4 ns/op
> 4685.7 ns/op
>
> NOTE: `fast` - was a patched node.js, `slow` - unpatched node.js with vanilla v8.
>
> BUG=
>
> Committed: https://crrev.com/9e3676da9ab1aaf7de3e8582cb3fdefcc3dbaf33
> Cr-Commit-Position: refs/heads/master@{#30495}

TBR=hpayer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

Revert of [turbofan] greedy: heuristic for memory operands (patchset #2 id:40001 of https://codereview.chromium.org/1306823005/ )

Reason for revert:
[Sheriff] Breaks test with greedy allocator:
http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug%20-%20greedy%20allocator/builds/1318

Original issue's description:
> [turbofan] greedy: heuristic for memory operands
>
> When we have a memory operand (HasSpillOperand() == true), and it
> doesn't need a register immediately, split in an optimal position, which
> is outside the outermost possible loop - just like Linear does.
>
> This results in some modest improvements in perf, when compared
> to baseline greedy. In particular Jetstream zlib x64: 4.66%, Life
> (Emscripten x64) 11%; largest regression is in AreWeFastYet x64: 8%
> and Corrections (Emsccripten x32) 10%
>
> BUG=
>
> Committed: https://crrev.com/8937bfc1d165ff6d72dede1b0ce6f7c1ab9fb260
> Cr-Commit-Position: refs/heads/master@{#30498}

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

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

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

This CL us a pure refactoring that makes an empty compilation unit
including just "isolate.h" or "contexts.h" but not "objects-inl.h"
compile without warnings or errors. This is needed to further reduce
the header dependency tangle.

R=bmeurer@chromium.org

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

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

The code was previously reading unsigned integers by performing an invalid cast
of Operator1<intNN_t> objects to Operator1<uintNN_t> and reading the integer
directly. To fix the invalid cast, we cast to the correct type and static_cast
the integer to uintNN_t, which is a no-op on every reasonable target.

Cleanup for cfi_vptr=1; see https://www.chromium.org/developers/testing/control-flow-integrity

BUG=chromium:457523
R=bmeurer@chromium.org
LOG=N

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

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

When we have a memory operand (HasSpillOperand() == true), and it
doesn't need a register immediately, split in an optimal position, which
is outside the outermost possible loop - just like Linear does.

This results in some modest improvements in perf, when compared
to baseline greedy. In particular Jetstream zlib x64: 4.66%, Life
(Emscripten x64) 11%; largest regression is in AreWeFastYet x64: 8%
and Corrections (Emsccripten x32) 10%

BUG=

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

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

Partially port https://codereview.chromium.org/1243373003/

BUG=chromium:515782
LOG=n
NOTRY=true

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

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

This CL introduces HPrologue instruction which does the context allocation work and supports deoptimization.

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

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

Remove intersection from the `std::map`s representing current live
ArrayBuffers. While being simpler to understand, it poses significant
performance issue for the active ArrayBuffer users (like node.js).

Store buffers separately, and process them together during mark-sweep phase.

The results of benchmarks are:

$ ./node-slow bench && ./node-fast bench
4997.4 ns/op
4685.7 ns/op

NOTE: `fast` - was a patched node.js, `slow` - unpatched node.js with vanilla v8.

BUG=

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

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

TBR=hablich@chromium.org
NOTRY=true

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

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

Fixes an invalid cast of an Operator1<StorePropertyParameters> object
to Operator1<LanguageMode> by reading the language mode from
StorePropertyParameters. This code happened to work before because
StorePropertyParameters's first field has type LanguageMode.

Cleanup for cfi_vptr=1; see https://www.chromium.org/developers/testing/control-flow-integrity

BUG=chromium:457523
R=bmeurer@chromium.org
LOG=N

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

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

We completely un-wired the greedy allocator to focus on the
stackchecks in loops (splintering) work. This change re-wires greedy,
still behind its flag. For now, enabling the greedy allocator disables
the stackchecks in loops feature (and range splintering), so that we are
at the baseline we left it at.

The main contribution in this change is adapting the codebase after
the live range model refactoring, whereby RegisterAllocationData's
live_ranges() contains just top-level ranges, and children are accessed
via their parents.

BUG=

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

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

We were previously reading a language mode from all comparison nodes
in JSGenericLowering::ReplaceWithCompareIC. This read was invalid for
{,Strict}{,Not}Equal nodes, as these nodes do not have a language mode, as they
derive from Operator rather than from Operator1<LanguageMode>. Because these
nodes are not language mode dependent, we arbitrarily pass Strength::WEAK
to CodeFactory::CompareIC.

Cleanup for cfi_vptr=1; see https://www.chromium.org/developers/testing/control-flow-integrity

BUG=chromium:457523
R=bmeurer@chromium.org
LOG=N

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

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

Revert of Fix CPU profiler deadlock on Windows + AMD CPU. (patchset #1 id:1 of https://codereview.chromium.org/1304873011/ )

Reason for revert:
Broke a test

Original issue's description:
> Fix CPU profiler deadlock on Windows + AMD CPU.
>
> Implement a lock free version of RolloverProtectedTickClock::Now
> to eliminate a deadlock.
>
> BUG=chromium:521420
> LOG=Y
>
> Committed: https://crrev.com/d6db8e5902af1f067f0f149844f4e92824ee93f3
> Cr-Commit-Position: refs/heads/master@{#30489}

TBR=yurys@chromium.org,caseq@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:521420

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

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

Implement a lock free version of RolloverProtectedTickClock::Now
to eliminate a deadlock.

BUG=chromium:521420
LOG=Y

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

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

The interrupts are already postponed in message handlers [1]. This CL aligns debug event listener (the mechanism that is actually used in Chrome DevTools) implementation with that. Handling interrupts on events like v8::AfterCompile leads to crashes like the one in the lined bug. This happens because in the interrupt handler we may change debugger state.

[1] https://codereview.chromium.org/309533009/diff/40001/src/debug.cc

BUG=chromium:520702
LOG=Y

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

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

TBR=mstarzinger@chromium.org
BUG=chromium:526244
LOG=N

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

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

This is a change for ES2015. Date objects have mutable state, so having
a mutable prototype is bad for SES requirements, and it is an
inconsistency from the typical ES2015 class style of objects

BUG=v8:4004
LOG=Y
R=adamk

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

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

Port fbad6366

Original commit message:
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments.  But currently we pass some semi-random value
(usually some stack address) after adapting arguments.

It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption.  Nevertheless this should be fixed.

BUG=

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

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

Assume a zone is in scope instead of a handles object.
Move INT32_TYPE into test-typing-reset.
Provide a CHECK_SKIP() macro to allow skipping
sections of an ast expression walk.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-typing-reset, test-ast-expression-visitor
R=rossberg@chromium.org,titzer@chromium.org
LOG=N

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

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

R=machenbach@chromium.org

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

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

Unbounded is defined in terms of None any Any,
which don't require an explicit zone.
Switching Unbounded to be the same.

BUG= None
TEST= trybots
R= titzer@chromium.org
LOG=N

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

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

Since we convert +x to x*1, we loose information about whether
the 1 was intended to be a floating point value for asm.js or not.

Mark the generated 1 as containing a dot (i.e. 1.0).

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

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

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

Port fbad6366

Original commit message:
    The call protocol requires that the register dedicated to the number of
    actual arguments (i.e. rax on x64) always contains the actual arguments.
    That means after adapting arguments it should match the number of
    expected arguments.  But currently we pass some semi-random value
    (usually some stack address) after adapting arguments.

    It looks like this is currently not observable anywhere, because our
    builtins and functions either don't look at the number of arguments and
    just make hard coded (unchecked) assumptions, or are marked as "don't
    adapt arguments", which bypasses the broken code in the trampoline for
    arguments adaption.  Nevertheless this should be fixed.

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

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

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

BUG=

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

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

R=mstarzinger@chromium.org
BUG=chromium:526244
LOG=N

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

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

Moving FastElements path to ElementsAccessor.

BUG=

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

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

This CL us a pure refactoring that makes an empty compilation unit
including just "frames.h" but not "handles-inl.h" compile without
warnings or errors. This is needed to further reduce the header
dependency tangle.

R=ishell@chromium.org

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

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

Unit tests for split/splinter/merge.

BUG=

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

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

R=mstarzinger@chromium.org

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

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

This way we don't need to expose JSReceiver::OrdinaryToPrimitive
as runtime function, and we don't need the separate JS trampoline.

This also adds tests for ToPrimitive on date objects, which are
special.

R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n

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

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

Rolling v8/tools/clang to 64370e74764d1fa9f50151d0e6025b0399370100

TBR=machenbach@chromium.org

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

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

- Move fast paths from builtins.cc ArraySlice to ElementsAccessor
- Handle more argument types in the fast path

BUG=

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

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

Revert of [simd.js] Disable SIMD polyfill. (patchset #2 id:20001 of https://codereview.chromium.org/1305923005/ )

Reason for revert:
Breaks simdjs performance tests. See:
https://paste.googleplex.com/5883927122149376

Original issue's description:
> [simd.js] Disable SIMD polyfill.
>
> Disable the polyfill in simd.js tests as the functions for Phase 1 have been implemented.
>
> BUG=v8:4124
> LOG=N
>
> R=bbudge@chromium.org, bmeurer@chromium.org, littledan@chromium.org
>
> Committed: https://crrev.com/749ba3a13558cb018a2ec783e5dfb56d2f8528d8
> Cr-Commit-Position: refs/heads/master@{#30452}

TBR=littledan@chromium.org,bmeurer@chromium.org,bradnelson@chromium.org,bbudge@chromium.org,gdeepti@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4124

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

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

BUG=

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

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

The default equality comparison operators and hashing functions for
Handles are ambiguous. The intended semantics might have either been
based on Handle locations or on object identity. This is why such
operators do not exist on Handle. The same argument applies to the
MaybeHandle class as well. Comments in that regard were also added.

R=bmeurer@chromium.org

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

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