With this CL the AstDecoder produces an error if it encounters a
grow_memory instruction in an asmjs module. Additionally asmjs
instructions are not allowed anymore in wasm modules.

BUG=chromium:644674
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2324733002
Cr-Commit-Position: refs/heads/master@{#39339}

This patch moves the following parsing method to ParserBase:

- ParseSwitchStatement

It also removes ParseCaseClause and merges it with ParseSwitchStatement,
mainly to avoid the complexity of introducing one more abstract typedef
to be shared between parser implementations, but also because the merged
ParseSwitchStatement is now only 59 lines.

R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2324843005
Cr-Commit-Position: refs/heads/master@{#39337}

  - Using realloc is still unsafe as the allocator, using array_buffer_allocator
  - Fixing tests to avoid overlapping stores, adding more tests

BUG=v8:5344

R=ahaas@chromium.org, mlippautz@chromium.org

Review-Url: https://codereview.chromium.org/2319983002
Cr-Commit-Position: refs/heads/master@{#39329}

Both legacy and AVX versions

BUG=

Review-Url: https://codereview.chromium.org/2328843003
Cr-Commit-Position: refs/heads/master@{#39327}

This patch moves the following parsing methods to ParserBase:

- ParseDoExpression
- ParseDoWhileStatement
- ParseWhileStatement
- ParseThrowStatement

R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2321103002
Cr-Commit-Position: refs/heads/master@{#39326}

Escape sequences may now be written to a trace file (previously,
any string with a valid escapable character would fail a check).

Also, string properties are now surrounded with quotes.

BUG=v8:4561

Review-Url: https://codereview.chromium.org/2309943005
Cr-Commit-Position: refs/heads/master@{#39319}

GetFunctionNameStr and GetScriptResourceNameStr can be called from a thread
other than isolate VM thread unlike their conterparts GetFunctionName
and GetScriptResourceName.

BUG=406277

Review-Url: https://codereview.chromium.org/2328673003
Cr-Commit-Position: refs/heads/master@{#39313}

This fixes a corner-case where the bytecode was using the <new.target>
register directly without going through the local variable. The value
might be clobbered because the deoptimizer doesn't properly restore the
value. The label will causes bytecode pipeline to be flushed and hence
ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore.

R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645103
BUG=chromium:645103

Review-Url: https://codereview.chromium.org/2325133002
Cr-Commit-Position: refs/heads/master@{#39306}

TBR=bmeurer@chromium.org
BUG=v8:5294

Review-Url: https://codereview.chromium.org/2324783002
Cr-Commit-Position: refs/heads/master@{#39304}

Before this change, the spread desugaring would naively call
`%AppendElement($R, the_hole)` and in some cases $R would have
a non-holey elements kind, putting the array into the bad state
of exposing holes to author code.

This patch avoids calling %AppendElement with a hole, instead
simply incrementing $R.length when it sees a hole in the literal
(this is safe because $R is known to be an Array). The existing
logic for elements transitions takes care of giving the array a
holey ElementsKind.

BUG=chromium:644215

Review-Url: https://codereview.chromium.org/2321533003
Cr-Commit-Position: refs/heads/master@{#39294}

This CL fixes %DebugPrint for FAST_HOLEY_DOUBLE_ELEMENTS and now properly
distinguishes TheHole and NaN values.

BUG=

Review-Url: https://codereview.chromium.org/2294913004
Cr-Commit-Position: refs/heads/master@{#39293}

BUG=v8:5363
R=adamk@chromium.org, littledan@chromium.org, cbruni@chromium.org

Review-Url: https://codereview.chromium.org/2328523002
Cr-Commit-Position: refs/heads/master@{#39291}

BUG=v8:4124
TEST:test-run-wasm-simd
R=titzer@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org

Review-Url: https://codereview.chromium.org/2300753005
Cr-Commit-Position: refs/heads/master@{#39288}

Adds support to collect allocation site feedback for Array function calls
to the call bytecode handler.

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

Review-Url: https://codereview.chromium.org/2307903002
Cr-Commit-Position: refs/heads/master@{#39283}

I could not reproduce the bug in either a unittest nor a cctest. That's
why I created an mjsunit test now.

BUG=chromium:644682
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2319213003
Cr-Commit-Position: refs/heads/master@{#39282}

The existing PropertyQueryCallback intercepts getOwnPropertyDescriptor, but
it returns only value and attributes, not the accessors. This
PropertyDescriptorCallback returns a descriptor similar to Ecma-262 6.2.4.

You can either set a PropertyQueryCallback or a PropertyDescriptorCallback,
but not both. When you set a callback for DefineProperty(), you can set a
PropertyDescriptorCallback but not a PropertyQueryCallback.

BUG=v8:5359

Review-Url: https://codereview.chromium.org/2311873002
Cr-Commit-Position: refs/heads/master@{#39279}

This fixes the materialization of JSFunction objects to not rely on a
context being available. The context has been cleared because it might
be de-materiallized itself.

R=bmeurer@chromium.org
TEST=mjsunit/compiler/escape-analysis-materialize
BUG=chromium:644245

Review-Url: https://codereview.chromium.org/2320983002
Cr-Commit-Position: refs/heads/master@{#39277}

The test was using some callee saved registers but tests don't save those.

BUG=v8:5354

Review-Url: https://codereview.chromium.org/2322923002
Cr-Commit-Position: refs/heads/master@{#39275}

BUG=chromium:636331
R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/2319683002
Cr-Commit-Position: refs/heads/master@{#39273}

Review-Url: https://codereview.chromium.org/2319173002
Cr-Commit-Position: refs/heads/master@{#39271}

This adds support to the deoptimizer to materialize ContextExtension
objects that have been de-materialized by escape analysis. This is
follow-up to the inline allocation of such objects during the create
lowering phase (i.e. JSCreateWithContext and JSCreateCatchContext).

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-644245
BUG=chromium:644245

Review-Url: https://codereview.chromium.org/2317353003
Cr-Commit-Position: refs/heads/master@{#39270}

When lowering Array.prototype.push/.pop to the fast inlined version, we
first need to ensure that all prototypes (including the Object.prototype)
are stable.

R=mvstanton@chromium.org
BUG=chromium:644689

Review-Url: https://codereview.chromium.org/2319533005
Cr-Commit-Position: refs/heads/master@{#39266}

BUG=

Review-Url: https://codereview.chromium.org/2304133002
Cr-Commit-Position: refs/heads/master@{#39265}

Reason for revert:
Breaks g++ build.

Original issue's description:
> [turbofan] ARM: Implement vswp and use in gap resolver
>
> Use vswp to switch double-precision registers in the gap resolver, with fall
> back temp register-based code if NEON is not available.
>
> BUG=
>
> Committed: https://crrev.com/2837c2e65a2ee5b9fc610f30ce1215f52323ecbd
> Cr-Commit-Position: refs/heads/master@{#39209}

BUG=

Review-Url: https://codereview.chromium.org/2314043002
Cr-Commit-Position: refs/heads/master@{#39264}

The optimization is not correct for unsigned output types, and we the
overall complexity seems too high. We need to find a better way to
take into account the input/output type restrictions.

Also added a regression test for the unsigned output bug.

BUG=v8:5267,v8:5270,v8:5357
TBR=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2320013002
Cr-Commit-Position: refs/heads/master@{#39262}

The trouble here is that the type of the induction variable might be
a bit ahead of the increment (JSAdd) operation's type. When we update
the type of the increment, we might only update the induction variable
type while the JSAdd type might be stale. If the induction variable typing
needs to fall back to normal phi typing (e.g., when the increment is not
an integer anymore), it might use the stale type.

To get around this, we fake monotonicity if we fallback to normal phi
typing. Another option would be to force re-typing of the increment
operation, but that seems to be harder to maintain.

BUG=chromium:644633

Review-Url: https://codereview.chromium.org/2320803002
Cr-Commit-Position: refs/heads/master@{#39261}

This patch fixes a bunch of out-of-date TODOs, un-skips some tests
and refers to appropriate bug numbers and current specification
status where appropriate.

R=adamk

Review-Url: https://codereview.chromium.org/2319203002
Cr-Commit-Position: refs/heads/master@{#39260}

Move it to HARMONY_STAGED bucket

Spec discussion:  https://github.com/tc39/ecma402/issues/30
It's in stage 4 and Firefox has already implemented it.

BUG=v8:5244
TEST=intl/date-format/date-format-to-parts.js
TEST=test262/intl402/DateTimeFormat/prototype/formatToParts/*

Review-Url: https://codereview.chromium.org/2317783003
Cr-Commit-Position: refs/heads/master@{#39258}

While fixing the bug, removed code duplication from super load/store
runtime calls, and inlined calls of Object::ReadAbsentProperty (left
over from strong mode).

BUG=v8:5335

Review-Url: https://codereview.chromium.org/2311413002
Cr-Commit-Position: refs/heads/master@{#39257}

This yields a ~5% serialization time improvement on typical JSON-esque data.
The approach taken matches json-stringifier fairly closely.

BUG=chromium:148757

Review-Url: https://codereview.chromium.org/2311063004
Cr-Commit-Position: refs/heads/master@{#39254}

Testcase regress/regress-353551 fails with stack overflow error on
ppc64, increasing stack-size to 1100 resolves the issue, but will
cause other platforms to fail similar to
https://codereview.chromium.org/2072533002.
For now, disabling the testcase on ppc64.

R=machenbach@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2314343002
Cr-Commit-Position: refs/heads/master@{#39253}

On PPC the testcase CodeSerializerLargeCodeObject fails as
the object gets allocated in the code_space section of
the heap. This is because the code_space gets expanded
successfully to 1 page size (4MB on PPC) and can accommodate
the object (size=3784608 bytes). Increasing size of the compiled
source to (5096192 bytes) so that code_space is not expanded and
the space is allocated in the Large Object space of the heap.
Testcase was added as part of https://codereview.chromium.org/2226233002

R=mstarzinger@chromium.org, bmeurer@chromium.org

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2314843003
Cr-Commit-Position: refs/heads/master@{#39252}

This is analogous to the variable liveness analysis we do in the AstGraphBuilder, but on the bytecode registers.

BUG=

Review-Url: https://codereview.chromium.org/2307863002
Cr-Commit-Position: refs/heads/master@{#39248}

We were previously incorrectly changing:
  sub r0, 0, r1
  cmp r2, r0
  b.cond <addr>
to:
  cmn r2, r1
  b.cond <addr>

for all conditions. This is incorrect for conditions involving the C (carry)
and V (overflow) flags, and in particular in the case where r1 = INT_MIN.
The optimization is still safe to perform for Equal and NotEqual since they
do not depend on the C and V flags.

BUG=

Review-Url: https://codereview.chromium.org/2318043002
Cr-Commit-Position: refs/heads/master@{#39246}

Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
Number.isSafeInteger and Number.isNaN predicates to TurboFan
builtins and make them optimizable (for certain input types) in
JavaScript callees being optimized by TurboFan. That means both
the baseline and the optimized version is now always at maximum,
consistent performance. Especially TurboFan suffered from poor
baseline (and optimized) performance because it cannot play the
same weird tricks that Crankshaft plays for %_IsSmi.

This also adds a bunch of new tests to properly cover the use
of the Harmony predicates in optimized code.

R=franzih@chromium.org
BUG=v8:5049,v8:5267

Review-Url: https://codereview.chromium.org/2313073002
Cr-Commit-Position: refs/heads/master@{#39242}

BUG=v8:5358

Review-Url: https://codereview.chromium.org/2316973002
Cr-Commit-Position: refs/heads/master@{#39240}

Now callers of Heap::CollectGarbage* functions need to
specify the reason as an enum value instead of a string.

Subsequent CL will add stats counter for GC reason.

BUG=

Review-Url: https://codereview.chromium.org/2310143002
Cr-Commit-Position: refs/heads/master@{#39239}

This reverts commit 332bd5e9.

BUG=chromium:636331
R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/2313243002
Cr-Commit-Position: refs/heads/master@{#39237}

Various test fixes for issues that get flushed out with smaller pages.

BUG=chromium:636331
R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/2313273002
Cr-Commit-Position: refs/heads/master@{#39235}

In ignition, allocation site mementos were disabled when creating array
literals. Enabled them in this cl.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2294913006
Cr-Commit-Position: refs/heads/master@{#39234}