An AdvancedReducer is basically a regular Reducer with an editor
that can perform graph editing operations beyond changing or
replacing the node that is currently being reduced. The GraphReducer
is the default implementation of the AdvancedReducer::Editor interface.

The ControlReducerImpl is now just an AdvancedReducer, which
temporarily requires a Finish method in the reducer to implement
the dead node trimming until we move that to the GraphReducer
(which in turn requires that all loops are connected to End).

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

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

R=mvstanton@chromium.org

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

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

TBR=yangguo@chromium.org
NOTRY=true

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

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

NOTRY=true
TBR=machenbach@chromium.org
BUG=4078
LOG=N

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

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

Revert of [V8] Reland https://codereview.chromium.org/1100993003/ (patchset #1 id:1 of https://codereview.chromium.org/1121833003/)

Reason for revert:
[Sheriff] Speculative revert for breaking layout tests - will reland if it doesn't help:
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064/builds/3178

Original issue's description:
> [V8] Reland https://codereview.chromium.org/1100993003/
>
> Chromium tests were prepared in https://codereview.chromium.org/1118743003/
> Blink tests in https://codereview.chromium.org/1115193002/
>
> LOG=Y
> BUG=chromium:480652
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/19b62e211d1829108e5c85c5043dd755afa17178
> Cr-Commit-Position: refs/heads/master@{#28229}

TBR=yangguo@chromium.org,kozyatinskiy@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:480652

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

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

port cf53fed9 (r28242).

original commit message:

    ArgumentsAdaptorStub for derived constructor (the one that needs
    new.target) works in this way:
     - If the constructor is invoked via the Construct stub, we know that
       actual arguments always include new.target. ``arguments`` object
       however should not include a new.target, therefore we remove it.
       We achieve this by decrementing the argument count.
     - If the constructor is invoked as a call, we do not care for a correct
       ``arguments`` array since the constructor will immediately throw on
       entrance.
    The bug is that the call could actually pass 0 actual arguments, but I
    decrement unconditionally :(. The fix is to detect this case and avoid
    decrementing. ``arguments`` is bogus, but it is ok as constructor
    throws.

    Long-term we should just remove mucking about with arguments for
    new.target and just get it from the stack.

BUG=

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

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

Rolling v8/tools/clang to 8ed88fc35e20182d6ecc3dde107606f609c46b23

TBR=machenbach@chromium.org

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

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

  "RunAllocate" test case is added in d6945db7. it invokes Linkage::GetStubCallDescriptor
   which is unimplemented for turbofan unsupported platform.

BUG=

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

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

As part of the migration from GYP->GN, we want to make sure that we
can track when new targets are added to either the GYP or GN builds
and that we are building everything we expect to build.

In GN, unlike GYP, if a build file gets referenced from other files,
building 'all' will cause every target to be built in it. This means in
particular, that we can end up trying to build targets that are not
necessarily intended to be visible to the rest of the build. To get
around this, any target that is defined but hidden (like 'v8_snapshot',
in V8's case) should still be visible to a top-level target called
"//:gn_visibility".

R=brettw@chromium.org, machenbach@chromium.org
BUG=461019
LOG=N

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

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

ArgumentsAdaptorStub for derived constructor (the one that needs
new.target) works in this way:
 - If the constructor is invoked via the Construct stub, we know that
   actual arguments always include new.target. ``arguments`` object
   however should not include a new.target, therefore we remove it.
   We achieve this by decrementing the argument count.
 - If the constructor is invoked as a call, we do not care for a correct
   ``arguments`` array since the constructor will immediately throw on
   entrance.
The bug is that the call could actually pass 0 actual arguments, but I
decrement unconditionally :(. The fix is to detect this case and avoid
decrementing. ``arguments`` is bogus, but it is ok as constructor
throws.

Long-term we should just remove mucking about with arguments for
new.target and just get it from the stack.

R=arv@chromium.org,rossberg@chromium.org
BUG=chromium:474783
LOG=Y

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

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

- Add long branche mode for FPU branches.
- Fix FPU branches for unordered conditions.
- Provide FPU [un]ordered condition negation schema.

TEST=mjsunit/miror-objects, constant-folding-2, external-array
BUG=

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

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

Improve d26f5d39

Original commit message:
When comparing a symbol to istself using <, <=, > or >= we need to
throw a TypeError. This is correctly handled in the runtime function
so if we are comparing a symbol fall back to use the runtime.

BUG=

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

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

Port d21de2a4

Original commit message:
Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).

Also explicitly limit tail call optimization to stubs for now and drop
the global flag.

R=dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Revert of Resolve references to "this" the same way as normal variables (patchset #11 id:240001 of https://codereview.chromium.org/1097283003/)

Reason for revert:
nosnap failures

Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=
> LOG=N
>
> Committed: https://crrev.com/18619d355192e2699203d12d9ebb9caea107b693
> Cr-Commit-Position: refs/heads/master@{#28236}

TBR=rossberg@chromium.org,mstarzinger@chromium.org,dslomov@chromium.org,adamk@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

Revert of Collect type feedback on result of Math.[round|ceil|floor] (patchset #13 id:230001 of https://codereview.chromium.org/1053143005/)

Reason for revert:
All sorts of performance regressions

Original issue's description:
> Collect type feedback on result of Math.[round|ceil|floor]
>
> By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.
>
> Committed: https://crrev.com/f36ecaf3a4d61568ca50a20718acce7dd5da9a5f
> Cr-Commit-Position: refs/heads/master@{#28215}

TBR=mvstanton@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.

Based on work by Adrian Perez de Castro <aperez@igalia.com>.

BUG=
LOG=N

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

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

Revert of [handles] Sanitize Handle and friends. (patchset #4 id:50001 of https://codereview.chromium.org/1128533002/)

Reason for revert:
[Sheriff] Breaks mac asan:
http://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/1198

Original issue's description:
> [handles] Sanitize Handle and friends.
>
> This almost allows us to get rid of handles-inl.h, once we fix the
> cyclic dependencies (follow up CL).
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3283195d0408333cce552cf4087577e6f41054e5
> Cr-Commit-Position: refs/heads/master@{#28222}

TBR=yangguo@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

otherwise phantom nodes won't ever be taken into account

BUG=chromium:484671,chromium:479796
R=hpayer@chromium.org
LOG=y

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

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

R=hpayer@chromium.org
BUG=

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

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

BUG=
R=danno@chromium.org

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

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

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

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

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

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

Chromium tests were prepared in https://codereview.chromium.org/1118743003/
Blink tests in https://codereview.chromium.org/1115193002/

LOG=Y
BUG=chromium:480652
R=yangguo@chromium.org

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

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

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

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

BUG=chromium:484589
LOG=n
NOTRY=true
TBR=hpayer@chromium.org

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

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

When comparing a symbol to istself using <, <=, > or >= we need to
throw a TypeError. This is correctly handled in the runtime function
so if we are comparing a symbol fall back to use the runtime.

BUG=v8:4073
LOG=Y
R=rossberg@chromium.org

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

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

BUG=v8:3925
LOG=NO

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

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

We do not expect to share maps for object literals created by builtin
Javascript code.

R=ishell@chromium.org

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

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

R=ishell@chromium.org

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

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

This almost allows us to get rid of handles-inl.h, once we fix the
cyclic dependencies (follow up CL).

R=yangguo@chromium.org

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

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

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

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

TBR=mvstanton@chromium.org
NOTRY=true

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

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

Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).

Also explicitly limit tail call optimization to stubs for now and drop
the global flag.

BUG=v8:4076
LOG=n

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

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

BUG=

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

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

TBR=machenbach@chromium.org

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

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

R=mvstanton@chromium.org

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

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

By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.

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

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

These macros are not needed anymore, so there's no point in supporting
them.

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

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

When we preprocess stack traces, we turn code pointer and offset to
source position, and store it in place of code pointer as smi.

Preprocessing stack traces is currently disabled due to issue 4065.

R=jkummerow@chromium.org

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

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

AIX compiler is complaining that variable may not be initialized

	modified:   src/heap/heap.cc

R=danno@chromium.org, svenpanne@chromium.org, mbrandy@us.ibm.com

BUG=

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

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