Port 38915ed7

Original commit message:
    This implements a mechanism to track the exact depth of the operand
    stack in full-codegen for every sub-expression visitation. So far we
    only tracked the depth at statement level, but not at expression level.
    With the introduction of do-expressions it will be possible to construct
    local control flow (i.e. break, continue and friends) that target labels
    at an arbitrary operand stack depth, making this tracking a prerequisite
    for full do-expression support.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4755,v8:4488
LOG=n

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

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

This patch moves the ES2015 Symbol.species feature from staging to
shipping. @@species should be good to ship now that the regression
from fast-path cases in concat, slice and splice have been addressed.

R=adamk
BUG=v8:4093
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

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

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

For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
metadata in wasm-compiler similar to DeoptimizationInputData.

Teach the basic backtrace to iterate over stack frames instead of JS frames.

Update the wasm stack test.

`git cl format` touches random lines in files I touch.

R=titzer@chromium.org
TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js

Originally landed in: https://codereview.chromium.org/1712003003/
Reverted in: https://codereview.chromium.org/1730673002/

This patch puts the JSFunction on the C++ stack.

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

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

The first operand to the CallRuntime class of bytecodes is the
ID of the runtime function being called. Before this commit
the ID was printed as plain uint16_t, now we get something like:

  B(CallRuntime) U16(Runtime::Add) ...

This change is intended to make both the golden files more
resistant to modifications of the i::Runtime::FunctionId enum
and the output of generate-bytecode-expectations more readable.

BUG=v8:4280
LOG=N

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

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

Now that register validation is working again, re-enable
for asm->wasm embenchen tests.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N

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

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

asm.js permits both:
int * constant
constant * int

It does not, however, allow intishes in multiplies.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm,test-asm-validator
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N

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

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

Revert of Add WasmFrame, backtraces reflect wasm's presence (patchset #9 id:160001 of https://codereview.chromium.org/1712003003/ )

Reason for revert:
[Sheriff] Seems to break gcmole:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/8295

Original issue's description:
> Add WasmFrame, backtraces reflect wasm's presence
>
> For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
> metadata in wasm-compiler similar to DeoptimizationInputData.
>
> Teach the basic backtrace to iterate over stack frames instead of JS frames.
>
> Update the wasm stack test.
>
> `git cl format` touches random lines in files I touch.
>
> R=titzer@chromium.org
> TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
>
> Committed: https://crrev.com/aeca945786dcccad3efecfddbf2c07aefa524a56
> Cr-Commit-Position: refs/heads/master@{#34220}

TBR=titzer@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,jfb@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/1730673002

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

For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
metadata in wasm-compiler similar to DeoptimizationInputData.

Teach the basic backtrace to iterate over stack frames instead of JS frames.

Update the wasm stack test.

`git cl format` touches random lines in files I touch.

R=titzer@chromium.org
TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js

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

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

R=titzer@chromium.org

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

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

Lost in the repo shuffle:
https://github.com/WebAssembly/v8-native-prototype/pull/102

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N

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

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

Adding a version of embenchen, modified to pass through
the asm->wasm javascript interface.
Disabling for now as fixes required to run it are outstanding.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/wasm/embenchen
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N

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

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

This filters test and third_party files to get a speed-up
when running tests and when collecting profile data.

BUG=chromium:568949
LOG=n
NOTRY=true

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

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

SuperPropertyArgumnets is less useful after deprecating strong mode.

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

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

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

TBR=rmcilroy@chromium.org
BUG=v8:4690
LOG=N

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

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

R=titzer@chromium.org

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

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

Slots pointing to evacuation candidates are now recorded in the new RememberedSet<OLD_TO_OLD>.

The remembered set is extended to support typed slots.

During parallel evacuation all migration slots are recorded in local slots buffers.
After evacuation all local slots are added to the remembered set.

BUG=chromium:578883
LOG=NO

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

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

This implements a mechanism to track the exact depth of the operand
stack in full-codegen for every sub-expression visitation. So far we
only tracked the depth at statement level, but not at expression level.
With the introduction of do-expressions it will be possible to construct
local control flow (i.e. break, continue and friends) that target labels
at an arbitrary operand stack depth, making this tracking a prerequisite
for full do-expression support.

R=rossberg@chromium.org,jarin@chromium.org
BUG=v8:4755,v8:4488
LOG=n

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

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

R=mcilroy@chromium.org
BUG=v8:4690
LOG=N

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

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

Until now inlining in TurboFan was staged behind --turbo, which means
that it wasn't enabled with --turbo-shipping. It seems reasonable to
ship it now, since Clusterfuzz had fun with it for a year already, and
we need to reach parity with Crankshaft with more and more things being
enabled behind --turbo-shipping.

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

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

So far counters did not work when they were reentrant and thus would lead to
wrong bookkeeping of the counter stack. Using a separate stack-allocated linked
list to track the timer stack solves this issue. This is a temporary workaround
with the limitations of the counter system in mind. Eventually we will move to
the trace-based system for these kind of statistics.

BUG=v8:4770
LOG=n

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

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

This fixes an issue encountered in wasm payloads, where we do not
(yet) optimize away duplicate phi definitions - phis in the same block
with the same operand list; and when move optimizations merge phi-
defining moves into the block defining the phi. If all this happens, the
register allocation validator back-propagation fails because it can't
distinguish the duplicate phis, when traversing backwards.

BUG=

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

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

When assigning to an integer view of the heap an intish
value does not need to be collapsed with |0.
Similarly a floatish value does not need to be collapsed with
fround when assigned to a float view of the heap.
i32[0] = i32_1 + i32_2;  // ok
f32[0] = f32_1 + f32_2;  // ok

However, floatish values cannot be safely assigned to double
arrays.
f64[0] = f32_1 + f32_2;  // not ok

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm,test-asm-validator
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N

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

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

  port e032a98d (r34190)

  original commit message:

BUG=

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

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

  port 0e43ff56 (r34187)

  original commit message:
  The InstructionSelector now associates an effect level to every node in a block.

  The effect level of a node is the number of non-eliminatable nodes encountered from the beginning of the block to the node itself.

  With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand if all of the following conditions hold:

  1. The only use of the load is in a 32 or 64 bit word comparison.
  2. The user node and the load node belong to the same block.
  3. The values of the operands have the same size (i.e., no need to zero-extend or sign-extend the result of the load).

BUG=

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

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

Rolling v8/buildtools to 97b5c485707335dd2952c05bf11412ada3f4fb6f

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

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

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

  The CL #33796 (https://codereview.chromium.org/1628133002) added the RunRoundUint32ToFloat32 test case and X87 failed at it.

  The reason is same as the CL #33630 (Issue 1649323002: X87: Change the test case for X87 RunRoundInt32ToFloat32), please refer: https://codereview.chromium.org/1649323002.

  Here is the key comments from CL #33630:
  Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
  those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
  The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
  The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.

  For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
  fail.

  So we add the following sentence to do type case to keep the same precision for RunRoundUint32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).

BUG=

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

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

It turns out that some old polyfill library uses
RegExp.prototype.flags as a way of feature testing. It's not clear
how widespread this is. For now, as a minimal workaround, we can
return undefined from getters like RegExp.prototype.global when
the receiver is RegExp.prototype. This patch implements that strategy
but omits a UseCounter to make backports easier.

R=adamk
CC=yangguo@chromium.org
BUG=chromium:581577
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

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

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

In ES2016, the Proxy enumerate trap is removed. This patch changes
for-in iteration on Proxies to use the ownKeys trap. Due to the clean
organization of that code, the patch basically consists of deletions.

R=adamk
LOG=Y
BUG=v8:4768

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

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

This patch makes ArraySpeciesCreate fast in V8 by avoiding two property reads
when the following conditions are met:
- No Array instance has had its __proto__ reset
- No Array instance has had a constructor property defined
- Array.prototype has not had its constructor changed
- Array[Symbol.species] has not been reset

For subclasses of Array, or for conditions where one of these assumptions is
violated, the full lookup of species is done according to the ArraySpeciesCreate
algorithm. Although this is a "performance cliff", it does not come up in the
expected typical use case of @@species (Array subclassing), so it is hoped that
this can form a good start. Array subclasses will incur the slowness of looking
up @@species, but their use won't slow down invocations of, for example,
Array.prototype.slice on Array base class instances.

Possible future optimizations:
- For the fallback case where the assumptions don't hold, optimize the two
  property lookups.
- For Array.prototype.slice and Array.prototype.splice, even if the full lookup
  of @@species needs to take place, we still could take the rest of the C++
  fastpath. However, to do this correctly requires changing the calling convention
  from C++ to JS to pass the @@species out, so it is not attempted in this patch.

With this patch, microbenchmarks of Array.prototype.slice do not suffer a
noticeable performance regression, unlike their previous 2.5x penalty.

TBR=hpayer@chromium.org

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

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

Port e032a98d

R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4690
LOG=N

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

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

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

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

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

The Proxy enumerate trap and Reflect.enumerate are removed from the
ES2016 draft specification. This patch removes the Reflect.enumerate
function, and a follow-on patch will be responsible for the Proxy
trap changes.

R=adamk
LOG=Y
BUG=v8:4768

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

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

In theory, a user could define the Symbol.isConcatSpreadable property
somewhere in the TypedArray class hierarchy. Array.prototype.concat
optimizes for this case and has templated code for fast concat over
TypedArrays. However, the default environment doesn't have this
property set (it would probably not be web-compatible) and there isn't
clear demand for this optimization. This patch removes that
special-case code.

R=adamk

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

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

Floating point param and return registers should be within the
compiler's allocatable set.

TEST=cctest/test-run-wasm-js/Run_Float64Add_jswrapped
R=titzer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Local testing suggests that optimized builds add more speed
without trading off tool usability. We get the following
differences (A: non-optimized build, B: optimized):

Sometimes: Lines instrumented in A (covered and uncovered) are not instrumented in B.
Rarely: Lines instrumented and covered in A are instrumented, but not covered in B.

The latter might simply be caused by timing differences in
the two builds.

BUG=chromium:568949
LOG=n
NOTRY=true

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

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

Currently AllocationSite skips the weak_next pointer in IterateBody and IsValidSlot.

This is not correct because the weak_next is a valid slot in AllocationSite.

BUG=

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

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

This picks the record-write stub depending on the correct remembered set
action parameter. For values known to be maps we can guarantee that they
never reside in new-space, hence store buffer recording can be skipped.

R=bmeurer@chromium.org

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

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

R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:4690
LOG=N

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

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

This removes a restriction from full-codegen that limited the usability
of the --debug-code flag to only no-snap configurations. The reasoning
for the restriction would still hold, if we ever put full-codegen code
into the snapshot, which we don't. Also there already are several places
in full-codegen that queried the FLAG_debug_code directly, a more
reliable mechanism will be needed if we snapshot full code.

R=yangguo@chromium.org

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

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

BUG=chromium:587574
LOG=NO

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

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