This moves the responsibility of preparing full-codegen code with
deoptimization support into the backends. This avoids generating such
code when optimization can be done directly from existing bytecode.

R=bmeurer@chromium.org
BUG=v8:4280
LOG=n

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

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

BUG=

Committed: https://crrev.com/5210f167e802a3758aac1f2900a6560c8de07831
Cr-Commit-Position: refs/heads/master@{#35231}

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

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

This has been fixed by 165186f2.

R=machenbach@chromium.org
BUG=v8:4893,v8:4894
LOG=N

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

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

Otherwise, they'll just keep growing until we run out of memory or hit the FixedArray's maximum capacity.

BUG=v8:4909
R=hpayer@chromium.org
LOG=n

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

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

We have trouble with Math.fround(MEM[...]).  Since we now properly type
LoadBuffer (it can produce undefined), lowering of fround has stopped
triggering (as it requires Number type).  This CL is a quick fix for this issue
- we simply trigger the lowering for NumberOrUndefined and let representation
selection/truncation analysis deal with this.

Ultimately, we would want to insert some 'simplified' ToNumber conversion
that would be optimized as much as possible during representation
selection.

BUG=chromium:603802
LOG=n
R=bmeurer@chromium.org

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

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

  port 911a5768 (r35301)

  original commit message:

BUG=

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

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

The current context is stored as a stack slot on the interpreter frame
and therefore we don't need to also maintain a machine register for the
context. Removes this register from bytecode handlers.

In the process modifies this frees up a register on ia32 to keep the
dispatch table pointer in a register rather than on a stack slot on
ia32.

BUG=v8:4280
LOG=N

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

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

  port 974721c6 (r35283)

  original commit message:
  Introduce a ResumeGeneratorTrampoline, which does the actual stack state
  reconstruction (currently always restores a fullcodegen frame), and
  introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
  %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
  this native builtin.

  Also unify the flooding in case of step-in to always work based on
  JSFunction and remove the special casing for JSGeneratorObject.

BUG=

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

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

R=jarin@chromium.org

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

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

  port 3dd3beb0 (r35199)

  original commit message:
  Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions
  for the use of a memory operand are met.

  This CL makes it possible to load only one of them into a register and address the other as a memory operand.

  The tricky bit is that, unlike as in the x64 counterpart http://crrev.com/1780193003, not all registers can be accessed as bytes.

BUG=

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

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

  The CL #35176 (https://codereview.chromium.org/1843983002) exposed one hidden bug in x87 turbofan code generation for kX87Float64ToUint32.

  The current kX87Float64ToUint32 code generation will destroy the input value in X87 FPU stack which will be used by the following code.

  This CL fixed this bug.

BUG=

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

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

The current code for testing the VEX.L flag, indicating whether
128-bit or 256-bit registers are being accessed, was erroneous
and always returned true (i.e. indicated 128-bit registers).

This patch fixes this behaviour and checks the flag correctly.

Ref: https://github.com/nodejs/node/issues/6151

BUG=

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

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

Rolling v8/buildtools to 5378d73123b64907773cc5c1bb027b2f765ff00a

Rolling v8/tools/clang to 41bff4c5ba97022c0fe69a59d8892a6c45fb0867

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

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

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

R=verwaest@chromium.org

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

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

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

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

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

The builtin context is not a thing anymore. This means we don't have to
worry about being able to deserialize it when optimizing top-level code.

R=bmeurer@chromium.org

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

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

Port 0c05e02f

Original commit message:
    Modifies Ignition to store code entry addresses in the dispatch table
    rather than code objects. This allows the interpreter to avoid
    calculating the code entry address from the code object on every
    dispatch and provides a ~5-7% performance improvement on Octane with
    Ignition.

    This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
    tail call dispatch using these code addresses. It also adds a Dispatch
    linkage creator (distinct from the stub linkage type used previously) to
    allow targetting a code address target (which will diverge further from
    the stub linkage type when we remove the context machine register in
    Ignition).

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=v8:4280
LOG=N

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

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

We will move this back to start of incremental marking when we make faster progress.

Perf sheriffs: This CL may cause a regression on benchmarks that improved earlier by enabling black allocation.

BUG=chromium:599174
LOG=n

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

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

This changes closure creation to lower to inline allocations when
possible instead of going through the FastNewClosureStub. It allows us
to leverage all advantages of inline allocations on closures. Note that
it is only safe to embed the raw entry point of the compile lazy stub
into the code, because that stub is immortal and immovable.

R=mvstanton@chromium.org

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

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

Revert of [build] Use MSVS 2015 by default. (patchset #4 id:60001 of https://codereview.chromium.org/1886983002/ )

Reason for revert:
Introduced flaky crashes on win debug.

Original issue's description:
> [build] Use MSVS 2015 by default.
>
> BUG=chromium:603131
> LOG=y
>
> Committed: https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900
> Cr-Commit-Position: refs/heads/master@{#35487}

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

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

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

BUG=

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

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

R=jkummerow@chromium.org
BUG=chromium:600257
LOG=N

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

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

BUG=chromium:603011
LOG=n
NOTRY=true

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

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

BUG=

Committed: https://crrev.com/4c2b04542f263b2679194f9fb75672ebbe72b924
Cr-Commit-Position: refs/heads/master@{#35330}

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

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

This allows us to remove the turbofan bailout that we introduced
as a response to crbug.com/589792.

BUG=chromium:589792
LOG=n

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

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

Otherwise the megamorphic stubcache will miss. It only probes for
non-keyed handlers.

BUG=

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

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

Revert of Correctly annotate eval origin. (patchset #5 id:80001 of https://codereview.chromium.org/1854713002/ )

Reason for revert:
performance impact

Original issue's description:
> Correctly annotate eval origin.
>
> There were a couple of issues with it:
> - interpreter is not supported
> - the source position was just accidentally correct for full-codegen
> - the eval origin could have been cached
>
> Also fixes a few other places to use AbstractCode.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
> Cr-Commit-Position: refs/heads/master@{#35257}
>
> Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16
> Cr-Commit-Position: refs/heads/master@{#35481}

TBR=mstarzinger@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/1888013002

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

The parser no longer disables optimization. This is done solely by the
renumbering stage. It is sufficient to mark a SharedFunctionInfo as
disabled for optimization right after the renumbering stage.

R=bmeurer@chromium.org

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

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

R=verwaest@chromium.org, bmeurer@chromium.org
BUG=chromium:603470
LOG=N

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

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

Replace ChangeFloat64ToTagged(ChangeTaggedToFloat64(x)) with x in the
SimplifiedOperatorReducer.

R=jarin@chromium.org

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

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

BUG=chromium:603131
LOG=y

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

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

R=ishell@chromium.org

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

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

- Get rid of fixing up pointers on the main thread
- Get rid of sweeping on the main thread

Instead:
- Record (and process afterwards) slots in parallel
- Add the pages to the concurrent sweeper as pointers have already been fixed

This reverts commit 6df04b29.

BUG=chromium:581412
LOG=N
TEST=cctest/test-compaction/*

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

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

BUG=v8:4915
LOG=N

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

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

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

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

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

This removes the flag in question. It just duplicates the corresponding
compilation hint in the underlying SharedFunctionInfo object. Now that
the backends should have a SharedFunctionInfo available most of the time
it is safe to use the cannonical predicate.

R=bmeurer@chromium.org

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

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

There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached

Also fixes a few other places to use AbstractCode.

R=mstarzinger@chromium.org

Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
Cr-Commit-Position: refs/heads/master@{#35257}

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

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

Modifies Ignition to store code entry addresses in the dispatch table
rather than code objects. This allows the interpreter to avoid
calculating the code entry address from the code object on every
dispatch and provides a ~5-7% performance improvement on Octane with
Ignition.

This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
tail call dispatch using these code addresses. It also adds a Dispatch
linkage creator (distinct from the stub linkage type used previously) to
allow targetting a code address target (which will diverge further from
the stub linkage type when we remove the context machine register in
Ignition).

BUG=v8:4280
LOG=N

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

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

Replaces the HCallRuntime instruction in HGraphBuilder::BuildBinaryOperation with a call to the corresponding TurboFan stub.

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

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

  port e6b6e554 (r35163)

  original commit message:
  In the earlier implementation of GenerateDoubleToObject the context
  is loaded from the parent's frame. rsi is clobbered because it is used
  to store kHoleNan constnat. It is not always safe to peek at
  the parents frame. Bytecode handlers have TypedFrame and the type of
  frame is stored at FP + 1. GenerateDoubleToObject expects context
  to be store at that place. In the current implementation rsi is pushed
  onto the stack and is popped when exiting this function.

BUG=

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

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