Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.

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

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

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

We don't have proper test coverage for the no-deoptimization code paths
in the JSGlobalObjectSpecialization reducer, and we will properly never
have any use for that code, so it just adds complexity and code that
likely breaks over time (as its untested).

R=jarin@chromium.org

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

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

The StackSlot operator allows to allocate a spill slot on the stack. We
are going to use this operator to pass floats through pointers to c
functions, which we need for floating point rounding in the case where
the architecture does not provide rounding instructions.

R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com

Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
Cr-Commit-Position: refs/heads/master@{#33600}

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

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

Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4 id:60001 of https://codereview.chromium.org/1645653002/ )

Reason for revert:
problems on Mac64

Original issue's description:
> [turbofan] Add the StackSlot operator to turbofan.
>
> The StackSlot operator allows to allocate a spill slot on the stack. We
> are going to use this operator to pass floats through pointers to c
> functions, which we need for floating point rounding in the case where
> the architecture does not provide rounding instructions.
>
> R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
>
> Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
> Cr-Commit-Position: refs/heads/master@{#33600}

TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

The StackSlot operator allows to allocate a spill slot on the stack. We
are going to use this operator to pass floats through pointers to c
functions, which we need for floating point rounding in the case where
the architecture does not provide rounding instructions.

R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com

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

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

avoid jump threading erasing the reconstruction of a frame, if the
frame was elided.

BUG=

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

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

Disabling it for anything else, to avoid compile time overhead.

BUG=

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

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

This CL reduces the memory overhead of escape analysis
by introducing a "copy on demand" strategy for virtual states
and virtual objects.

BUG=v8:4586
LOG=n

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

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

The motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.

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

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

* Treat Select nodes as escaping
* Correctly void virtual field information
  after a store to a non-const index
* Add a shortcut if all allocates escape
* Add a shortcut if no allocates are discovered
* Only reduce FrameState/StateValues nodes if they
  have virtual allocates as input (transitively)
* Fix bug in FrameState/StateValues duplication
* Add check to verifier: First 3 inputs of FrameState
  must be StateValues

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

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

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

After 1564083002, spread expressions are desugared and should not
survive in the AST after parsing. This patch removes dead code
related to this.  It also eliminates the kSpread bailout reason
and the concat_iterable_to_array_builtin.

R=bmeurer@chromium.org
BUG=

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

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

This bug improves performance of escape analysis.

* A allocation discovery phase  (EscapeAnalysis::AssignAliases)
  ensures compact representation of virtual state
* Node revisiting in EscapeStatusAnalysis has been improved
* Escape analysis no longer requires a trimmed graph

BUG=v8:4586
LOG=n

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

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

R=bmeurer@chromium.org
BUG=

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

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

Adds FrameState nodes to graphs built by the Bytecode Graph Builder, in
preparation for adding deopt support. Also adds a new
FrameStateType::kInterpretedFunction to allow for specialized deopt
stack translation for interpreted frames. Finally adds support for
disabling typed lowering of binary ops, since the current approach
relies on a FrameState hack which does not apply to interpreted frames

BUG=v8:4280
LOG=N

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

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

This removes the ability to generate stub code via the full-fledged
compiler pipeline that parses and analyzes JavaScript source code.
Generation of stub code has been moved to a lower-level entry point.

R=bmeurer@chromium.org

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

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

This uses the same pipeline entry function for all three assemblers
currently supported by TurboFan. The Pipeline::GenerateCodeForCodeStub
is by now generic enough to accommodate all uses.

R=vogelheim@chromium.org

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

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

Bugfixes and improvements in escape analysis include:

* Handling of ObjectIsSmi (non-escaping)
* Handling of nested phi replacements
* Handling of phis with arity > 2
* Resilience against effectful nodes dangling from start
* Allocations escape now, if non-const load/store is performed
* Fixed a bug where non-allocated objects where tracked
* Allow fixed double arrays to be tracked

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

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

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

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

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

MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic

Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.

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

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

Fully scheduled graphs built by the RawMachineAssembler are inherently
not schedulable, they are missing effect and control dependencies, which
makes them not pass the graph verifier either. They do however pass the
schedule verifier.

R=titzer@chromium.org

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

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

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

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

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

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n

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

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

This is the first part of escape analysis for turbofan.
At the moment, there is no deopt support, and support
for loops is partial (only binary Phis are handled).

The CL includes 4 unittests.

There are also 8 new mjsunit tests, some of which are
skiped as they require features not yet implemented.

BUG=v8:4586
LOG=n

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

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

This is the initial support for binary operation hints on javascript
binary operators, i.e. JSAdd, JSSubtract and so on. The hints are
extracted from the fullcodegen code object before graph building and the
AstGraphBuilder puts those hints on the operators if available.

R=jarin@chromium.org
BUG=v8:4583
LOG=n

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

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

Revert of binary-operator-reducer: reduce mul+div(shift) (patchset #11 id:200001 of https://codereview.chromium.org/1350223006/ )

Reason for revert:
This is also unsound for the reasons outlined in
https://codereview.chromium.org/1473073004/
Will help Fedor to implement a solution based on simplified operators.

Original issue's description:
> binary-operator-reducer: reduce mul+div(shift)
>
> Reduction Input:
>
>     ChangeInt32ToFloat64=>          TruncateFloat64ToInt32
>                          Float64Mul=>
>     ChangeInt32ToFloat64=>          Float64Div=>TruncateFloat64ToInt32
>
> Output:
>
>          =>  TruncateInt64ToInt32
> Int64Mul
>          =>  Int64Shr => TruncateInt64ToInt32
>
> Test code:
>
>     function mul(a, b) {
>       var l = a & 0x3ffffff;
>       var h = b & 0x3ffffff;
>       var m = l * h;
>
>       var rl = m & 0x3ffffff;
>       var rh = (m / 0x4000000) | 0;
>
>       return rl | rh;
>     }
>
>     mul(1, 2);
>     var a0 = mul(0x3ffffff, 0x3ffffff);
>     mul(0x0, 0x0);
>     %OptimizeFunctionOnNextCall(mul);
>     var a1 = mul(0x3ffffff, 0x3ffffff);
>
>     print(a0 + ' == ' + a1);
>
> BUG=
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/461e5b49d022335a7fc4e9d172397a4bd48b93d4
> Cr-Commit-Position: refs/heads/master@{#31899}

TBR=mstarzinger@chromium.org,danno@chromium.org,titzer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

Revert of [compiler] merge binary-operator-reducer (patchset #2 id:20001 of https://codereview.chromium.org/1473073004/ )

Reason for revert:
Unsound use of types in the MachineOperatorReducer. Will work on a sound solution with Fedor.

Original issue's description:
> [compiler] merge binary-operator-reducer
>
> Merge BinaryOperatorReducer into the MachineOperatorReducer class.
> It does not need `Revisit()` calls, because the newly inserted nodes are
> visited anyway, and there are no other methods that need AdvancedReducer
> there.
>
> BUG=
> R=titzer@chromium.org
>
> Committed: https://crrev.com/993ba9d2529a6401b3040b9263f8d06db7dbb4f1
> Cr-Commit-Position: refs/heads/master@{#32298}

TBR=titzer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

BUG=

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

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

Merge BinaryOperatorReducer into the MachineOperatorReducer class.
It does not need `Revisit()` calls, because the newly inserted nodes are
visited anyway, and there are no other methods that need AdvancedReducer
there.

BUG=
R=titzer@chromium.org

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

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

Some highlights of this CL:
* Refactor the mutable state out of Frame into FrameAccessState,
  which is maintained and updated during code generation to
  record whether sp- or fp-based frame access is currently active
  and how deep the stack on top of the frame is.
* The operand resultion in linkage.cc now uses FrameAccessState
  to determine how to generate frame-accessing operands.
* Update all platforms to accurately track additionally pushed
  stack slots (e.g. arguments for calls) in the FrameAccessState.
* Add a flag, --turbo_sp_frame_access, which forces all frame
  access to be sp-based whenever possible. This will likely never
  be used in production, but for testing it's useful in verifying
  that the stack-tracking of each platform maintained in the
  FrameAccessState is correct.
* Use sp-based frame access for gap resolving before tail
  calls. This will allow for slightly more efficient restoration
  of the frame pointer in the tail call in a later CL.
* Remove most ad hoc groping into CallDescriptors to
  determine if a frame is needed, instead consistently use
  predicates like needs_frame(), IsCFunctionCall() and
  IsJSFunctionCall().

BUG=v8:4076
LOG=n

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

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

Introduce a JSCreateArray operator that represents the Array
constructor, and lower call and construct calls to the Array
constructor to JSCreateArray. Currently we don't yet replace
that with an inline allocation, but always use the specialized
stubs for the Array constructor.

This saves a lot of unnecessary deopts and elements transitions
because now we can actually consume the allocation site feedback
for the transitions.

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

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

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

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}

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=yangguo@chromium.org
BUG=v8:4470
LOG=n

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

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

The JSCallReducer runs together with inlining and tries to strength
reduce JSCallFunction nodes; currently it can fold
Function.prototype.call and Function.prototype.apply (with arguments),
and make it possible to inline across them.

In the case of Function.prototype.apply with arguments we still have to
leave the JSCreateArguments node in the graph because there might be
other (frame state) uses. Once escape analysis is ready, it will take
care of removing these nodes and adding appropriate transitions for the
deoptimizer.

R=jarin@chromium.org
BUG=v8:4551
LOG=n

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

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

This patch extends the typed lowering with a specialized version of 'instanceof' that is used if the "class", i.e. the constructor function, is a known constant.

Unittests check that replacement occurs as intended. Functional correctness is ensured by extensive unit tests covering instanceof already in the testsuite.

TESTS=unittests/JSTypedLoweringTest.{JSInstanceOfSpecializationWithSmiCheck,JSInstanceOfSpecializationWithoutSmiCheck,JSInstanceOfNoSpecialization}

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

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

Reduction Input:

    ChangeInt32ToFloat64=>          TruncateFloat64ToInt32
                         Float64Mul=>
    ChangeInt32ToFloat64=>          Float64Div=>TruncateFloat64ToInt32

Output:

         =>  TruncateInt64ToInt32
Int64Mul
         =>  Int64Shr => TruncateInt64ToInt32

Test code:

    function mul(a, b) {
      var l = a & 0x3ffffff;
      var h = b & 0x3ffffff;
      var m = l * h;

      var rl = m & 0x3ffffff;
      var rh = (m / 0x4000000) | 0;

      return rl | rh;
    }

    mul(1, 2);
    var a0 = mul(0x3ffffff, 0x3ffffff);
    mul(0x0, 0x0);
    %OptimizeFunctionOnNextCall(mul);
    var a1 = mul(0x3ffffff, 0x3ffffff);

    print(a0 + ' == ' + a1);

BUG=
R=mstarzinger@chromium.org

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

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

This makes sure that --trace-turbo or --turbo-source-positions does not
completely disable inlining. The recent introduction of a finalization
interface to the reducer borked the SourcePositionWrapper reducer.

R=bmeurer@chromium.org

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

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

Introduce Reducer::Finalize, which get's called by the GraphReducer once
all reductions are done, and use this to implement full inlining as part
of the regular reducer fixpoint.

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

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

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

The JSNativeContextSpecialization class is getting rather huge with all
the stuff related to property and element access going in. Splitting off
the global object related stuff into JSGlobalObjectSpecialization seems
like a natural separation, especially since the global object
specialization is sort of separate issue anyway.  This is neutral
functionality- and performance-wise.

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

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

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

Introduce new typing rules for LoadField[Map], which try to take into
account stable map information if the object either has type Constant or
type Class. If the map of the object is stable but can transition we
have to introduce a code dependency in the Typer to make sure that the
information (the Constant type we infer for LoadField[Map]) is valid
(and stays valid).

This also settles the policy for depending on map stability: The
definition can introduce any number of maps, without having to pay
attention to stability (i.e. you can always use Type::Class to introduce
a map that is propagated along the value edges), and the use site is
responsible for checking that the type information is valid before using
it. I.e. if you use stable map information, you'll have to add a
stability dependency (or make sure the map cannot transition).

Drive-by-improvement: Add ReferenceEqualTyper which takes input types
into account for improved constant folding.

Drive-by-fix: Apply policy mentioned above to JSNativeContextSpecialization.

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

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

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

    register configurations currently. This CL provides a mechanism so that
    optimizing compilers can select different Register Configuration.

BUG=

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

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