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

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

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

This triggers TurboFan whenever functions containing spread expressions
of any kind are marked for optimization. Note that this increases the
set of functions being eligible for optimization.

R=rossberg@chromium.org,hablich@chromium.org

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

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

R=bmeurer@chromium.org
BUG=

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

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

This makes sure we are using the right signedness - either the input
specifies signedness or the use must declare it does not care.

This requires some hole-punching in for-in so that the
representation selector understands the smi-ness of index.
Moreover, phi needs to pass the truncation along (maybe
slightly scary).

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

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

This ensures the class in question specifies the correct equality and
hashing function when instantiated. Note that this introduces two new
structs (i.e. OpEqualTo and OpHash) which can be used for defaults
within OpParameter as well.

R=titzer@chromium.org,bmeurer@chromium.org
TEST=cctest/test-operator

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

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

This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread

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

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

...based on the 2-lock algorithm by M. Scott and M. Michael (1992).

BUG=chromium:524425
LOG=N

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

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

BUG=

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

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

Retrieve the native context/global object from the Node being
specialized in the JSNativeContextSpecialization and the
JSGlobalObjectSpecialization classes. For this we introduce two
new methods NodeProperties::GetSpecializationNativeContext and
NodeProperties::GetSpecializationGlobalObject, which walk up
the context chain and might in the end take the native context
from the outermost activation (if native context specialization
is enabled). This allows us to run the native context specialization
pass as part of the inlining phase without hacking some of that into
the JSInliner.

Also refactor the NodeProperties::GetSpecializationContext method
that was previously local to the JSContextSpecialization.

Also refactor two other oddities in JSNativeContextSpecialization.

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

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

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

If the input type does not help us, we are conservative and truncate (rather than guessing signed).

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

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

This CL brings us one step closer to untangle the runtime-gc dependency, i.e. RecordWrites should not be called from the runtime.

BUG=

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

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

  port 14ec485c (r32044)

  original commit message:

BUG=

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

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

BUG=4134
R=epertoso@chromium.org
LOG=n

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

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

I found this optimization opportunity when analyzing some pathological
compile-time examples. When tying together live ranges across control
flow boundaries, we used to repeatedly check if the top level range was
spilled in deferred blocks or not. This proved to be a hotspot in such
cases (i.e. the pathological compile time ones).

Because the analysis needs to progress block by block and not live range by live range, we cannot feasibly save per-range information to
remove the hotspot. Instead, we save this information when
constructing LiveRangeBounds.

The result is 2.5 to 7% improvement in the pathological cases, and a few
similar bonuses in perf in a couple of other benchmarks.

Also, opportunistically removed the loop counting the number of child
ranges, since we have that count from the new (post - refactoring)
range numbering technique.

BUG=

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

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

Lower access to byteOffset and byteLength getters on JSArrayBufferViews
and to length on JSTypedArrays. This requires a check to see whether the
backing JSArrayBuffer was neutered.

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

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

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

  port 906903ac (r32043)

  original commit message:

BUG=

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

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

  port e75e6254 (r32040)

  original commit message:

BUG=

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

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

  port 07c1d181 (r32023)

  original commit message:

BUG=

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

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

Rolling v8/tools/clang to ccc0be4f85403b607fd7426cb86c4db2f49b02f6

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

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

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

Proxies are not properly supported yet.

This is a reland of 1405243006.

TBR=rossberg@chromium.org

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

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

BUG=497295
LOG=n

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

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

R=cbruni, rossberg
BUG=

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

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

TEST=unittests/InstructionSelectorTest/Word32ShrWithWord32AndWithImmediate,
     Word32AndWithImmediateWithWord32Shr, Word64AndWithImmediateWithWord64Shr,
     Word64AndWithImmediateWithWord64Shr
BUG=

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

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

TEST=unittests/InstructionSelectorTest.CombineShiftsWithMul,
     InstructionSelectorTest.CombineShiftsWithDivMod
BUG=

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

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

Port 14ec485c

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

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

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

Port e5edd66d

Original commit message:
    This is the first part to refactoring the JSNativeContextSpecialization
    class, which has grown way too big recently.

    Also don't collect cross context feedback for the CallIC in general.
    Neither TurboFan nor Crankshaft can make any use of cross context
    JSFunction feedback that is collected by the CallIC, so there's no
    point in gathering that feedback at all (it just complicates the
    checking that is necessary in the compilers). What we should do
    instead at some point (when Crankshaft becomes less important) is
    to collect the SharedFunctionInfo as feedback for those cases.

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

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

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

Port e75e6254

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

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

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

The current typing-asm mishandles the relationship between
unsigned numbers and int. Restructuring and using type shortcuts
that approximate asm types.

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

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

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

Port 906903ac

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

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

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

Port 07c1d181

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

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

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

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

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

BUG=

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

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

Per http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors (13.2.2),
make it a SyntaxError if an Identifier has the same StringValue as a ReservedWord.

BUG=v8:2222, v8:1972
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, wingo@chromium.org

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

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

BUG=

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

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

With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal

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

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

Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.

Landed on behalf of rmcilroy.

TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N

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

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

With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal

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

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

With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal

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

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

Several changes are included here:

1. Each resolution callback references shared data indicating whether
it has already been resolved or not, as described in 25.4.1.3
http://tc39.github.io/ecma262/#sec-createresolvingfunctions.
Previously this was handled exclusively by the Promise's status,
which does not work correctly with the current chaining behaviour.

2. During fulfillment, When a Promise is resolved with a thenable, the
spec chains the promises together by invoking the thenable's `then`
function with the original Promise's resolve and reject methods (per
section 25.4.2.2, or
http://tc39.github.io/ecma262/#sec-promiseresolvethenablejob, on the
next tick, regardless of whether or not there are pending tasks.

3. Adds a spec compliance fix to ensure that the Promise constructor
is only loaded once when `then()` is called, solving v8:4539 as well.
This involves refactoring PromiseChain to accept a constructor
argument. PromiseChain/PromiseDeferred will hopefully be removed soon,
simplifying the process.

BUG=v8:4162, v8:4539, v8:3237
LOG=N
R=rossberg@chromium.org, littledan@chromium.org, adamk@chromium.org

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

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

This disables the eager flushing of optimized code maps during full GCs
and instead treats entries in those tables weakly by default. Note that
for now entries are removed when one of its components dies.

R=mvstanton@chromium.org

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

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