We know it's a postive integer

BUG=
R=bmeurer@chromium.org

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

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

BUG=
R=bmeurer@chromium.org

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

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

The keys are always positive integers, so use an
UnseededNumberDictionary to store them instead of an ObjectHashTable

R=bmeurer@chromium.org

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

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

When operating in --rebaseline mode, each of the files will be updated.
In --raw-js mode, all the expectations will be written to the same file.
In default mode no more than one input file is accepted.

On POSIX systems, --rebaseline will autodiscover golden files when run
from the project root and no input file is provided.

BUG=v8:4280
LOG=N

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

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

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

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

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

The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).

This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.

R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y

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

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

Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.

The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.

Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.

Still to do is tracking source positions which will be done in a
followup CL.

BUG=v8:4766
LOG=N

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

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

Everything that HCallJSFunction does can be easily done using more general HInvokeFunction, so there's no need to have this dedicated instruction around.

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

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

Extends the constant pool to deal with more slices.

Adds ReadUnalignedUInt32().

BUG=v8:4280,v8:4747
LOG=N

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

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

We don't need to compare the result of ToObject against null, since
ToObject will always yield a proper receiver (or throw a TypeError).

R=rmcilroy@chromium.org

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

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

The %TailCall runtime entry and the %_TailCall intrinsic is not used,
and will never be used (because %TailCall doesn't actually do a tail
call). We will soon have proper ES6 tail calls, which are correct and
properly tested.

The %Apply runtime entry is basically a super-slow, less correct version
of Reflect.apply, so we can as well just use Reflect.apply, which is
exposed to builtins via %reflect_apply.

R=ishell@chromium.org

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

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

The %_Call intrinsic (if supported by the compiler) is lowered directly
to the Call builtin and thus throws a TypeError if the target is not
callable. The %Call runtime function also eventually calls into the Call
builtin, but had an early abort if the target is not a JSReceiver, which
is unnecessary and leads to various test failures for Ignition.

R=mvstanton@chromium.org

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

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

The treatment of different undetectable objects was inconsistent after
the latest changes to the undetectable bit in the maps. Given two
different undetectable JSObjects a and b, a monomorphic CompareIC would
say false for a == b, while the rest of the system (including the
generic case for the CompareIC) would say true.

The fix is rather straight-forward: We just go generic on a CompareIC
once we see an undetectable JSObject.

R=yangguo@chromium.org

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

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

Revert of Make Intl install properties more like how other builtins do (patchset #1 id:1 of https://codereview.chromium.org/1733293003/ )

Reason for revert:
Breaks a bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/6812

Original issue's description:
> Make Intl install properties more like how other builtins do
>
> Intl has been somewhat of an oddball for how it integrates with V8.
> One aspect is that it largely didn't use utils to install itself
> into the snapshot, which led to some missing names, which new
> test262 tests check for, and duplicated code. This patch brings
> Intl a bit closer to how the rest of the builtins do things, though
> not entirely as it is currently structured to do unusual things,
> such as creating new constructors from JavaScript rather than C++.
> New test262 tests check for some of the names that are added in
> this patch.
>
> R=adamk
> CC=jshin
> BUG=v8:4778
> LOG=Y
>
> Committed: https://crrev.com/a40830577d80f699282dd83864619656b7a7966c
> Cr-Commit-Position: refs/heads/master@{#34311}

TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4778

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

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

Revert of Test262 roll, 2016-2-23 (patchset #2 id:20001 of https://codereview.chromium.org/1738033002/ )

Reason for revert:
An Intl change that this depends on breaks a bot

Original issue's description:
> Test262 roll, 2016-2-23
>
> R=adamk
>
> Committed: https://crrev.com/34492040fbfb04fead21416245c8696b9847e751
> Cr-Commit-Position: refs/heads/master@{#34312}

TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

R=adamk

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

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

Intl has been somewhat of an oddball for how it integrates with V8.
One aspect is that it largely didn't use utils to install itself
into the snapshot, which led to some missing names, which new
test262 tests check for, and duplicated code. This patch brings
Intl a bit closer to how the rest of the builtins do things, though
not entirely as it is currently structured to do unusual things,
such as creating new constructors from JavaScript rather than C++.
New test262 tests check for some of the names that are added in
this patch.

R=adamk
CC=jshin
BUG=v8:4778
LOG=Y

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

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

BUG=v8:4315
R=adamk
LOG=Y

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

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

Rolling v8/base/trace_event/common to 81b7b6f531ad2375140b2a5f4d3a803e5ba2514c

Rolling v8/buildtools to 14288a03a92856fe1fc296d39e6a25c2d83cd6cf

Rolling v8/tools/swarming_client to a72f46e42dba1335e8001499b4621acad2d26728

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

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

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

Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of https://codereview.chromium.org/1722193002/ )

Reason for revert:
Speculative revert in attempt to fix #2 crasher on canary.

Original issue's description:
> [compiler] Drop the CompareNilIC.
>
> Since both null and undefined are also marked as undetectable now, we
> can just test that bit instead of having the CompareNilIC try to collect
> feedback to speed up the general case (without the undetectable bit
> being used).
>
> Drive-by-fix: Update the type system to match the new handling of
> undetectable in the runtime.
>
> R=danno@chromium.org
>
> Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba
> Cr-Commit-Position: refs/heads/master@{#34237}

TBR=danno@chromium.org,verwaest@chromium.org,bmeurer@chromium.org
LOG=y
BUG=chromium:589897
NOTRY=true

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

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

This patch moves iterator finalization (calling .return() when a
for-of loop exits early) to shipping. The only part of this feature
which is currently known to be missing is destructuring--.return()
should be also be called when destructuring with an array which
does not end in a rest pattern, but it currently does not. The rest
of this feature, including calling .return() from certain builtins,
is implemented.

R=adamk
BUG=v8:3566
LOG=Y

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

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

Port 55b4df73

Original commit message:
    Only use one set of %StrictEquals/%StrictNotEquals and
    %Equals/%NotEquals runtime entries for both the interpreter
    and the old-style CompareICStub. The long-term plan is to
    update the CompareICStub to also return boolean values, and
    even allow some more code sharing with the interpreter there.

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

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

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

This calback is run after an attempt to run microtasks.

BUG=chromium:585949
LOG=Y

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

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

BUG=v8:4781
LOG=NO

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

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

Only use one set of %StrictEquals/%StrictNotEquals and
%Equals/%NotEquals runtime entries for both the interpreter
and the old-style CompareICStub. The long-term plan is to
update the CompareICStub to also return boolean values, and
even allow some more code sharing with the interpreter there.

R=mstarzinger@chromium.org

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

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

Reland "Replace slots buffer with remembered set. (patchset #14 id:250001 of https://codereview.chromium.org/1703823002/ )"

This reverts commit 9146bc5e.

This contains a fix for the following crash:
1. We record slots for a fixed array.
2. We trim the fixed array, so that some recorded slots are now in free space.
3. During mark-compact we sweep the page with the fixed array. Now free list items contain memory with recorded slots.
4. We evacuate a byte array using the new free list items.
5. We iterate slots that are now inside the byte array and crash.

BUG=chromium:589413,chromium:578883
LOG=NO

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

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

operators.'

Port c129aa4d

Original commit message:
These macro operators represent a conditional eager deoptimization exit
without explicit branching, which greatly reduces overhead of both
scheduling and register allocation, and thereby greatly reduces overall
compilation time, esp. when there are a lot of eager deoptimization
exits.

BUG=
TEST=mjsunit/asm/embenchen/fasta

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

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

Port 1f5b84e4

TEST=test-run-machops/RunInt64SubWithOverflowImm, test-run-machops/RunInt64AddWithOverflowImm
BUG=

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

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

R=rmcilroy@chromium.org

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

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

It is possible for JS objects to be allocated while we are retrieving the
profile. These JS objects can in turn end up getting sampled by the profiler.
Adding these to the profile data structures invalidates the iterators that
are presently in flight. This change prevents such concurrent modifications
from affecting the retrieve operation.

BUG=

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

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

This adds explicit setters for the SharedFunctionInfo::function_data
field. Such setters are safer because they allow for explicit checking
of which values are allowed, and they improve readability because the
intended semantics become clear for each call-site. Also fix a cctest
case along the way.

R=rmcilroy@chromium.org

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

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

We should prefer hints from operands in non-deferred blocks, else we
risk sideways moves on the hot path, just to accommodate the register
allocator's choice of register assignment in the deferred block.

BUG=

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

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

BUG=chromium:589413
LOG=NO

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

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

BUG=
R=littledan@chromium.org

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

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

By now the deprecation of strong mode is far enough along that the
support present in the interpreter matches the support in the other
compilers. Special expectations aren't needed anymore.

R=rmcilroy@chromium.org

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

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

No need to go to the runtime to create a RegExp literal in Ignition, the
stub can handle everything.

R=rmcilroy@chromium.org

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

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

We otherwise would print the \n from the last line.

R=vogelheim@chromium.org

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

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

The steps are slow on dev workstations. Having them
run by the bots should be enough. The bots pass the mode
explicitly.

BUG=chromium:535160
LOG=n
TBR=tandrii@chromium.org, kjellander@chromium.org

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

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

The ForInStep bytecode is essentially a (guaranteed) Smi increment
operation. We can do not need to go to the runtime for this operation.

R=oth@chromium.org

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

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

We already have stubs for ToName, ToObject and ToNumber, so we can just
use them for Ignition instead of the generic runtime calls.

R=rmcilroy@chromium.org

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

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