With the original implementation nodes which were not reachable from end
could cause the verification to fail.

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

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

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

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n

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

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

R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org
BUG=v8:3956
LOG=Y

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

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

BUG=593359
LOG=y

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

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

  port 240b7db9 (r34630)

  original commit message:
  I implemented I64ShrU and I64ShrS the same as I64Shl in https://codereview.chromium.org/1756863002

BUG=

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

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

  port 9dcd0857 (r34571)

  original commit message:
  Before this CL, various code stubs used different techniques
  for marking their frames to enable stack-crawling and other
  access to data in the frame. All of them were based on a abuse
  of the "standard" frame representation, e.g. storing the a
  context pointer immediately below the frame's fp, and a
  function pointer after that. Although functional, this approach
  tends to make stubs and builtins do an awkward, unnecessary
  dance to appear like standard frames, even if they have
  nothing to do with JavaScript execution.

  This CL attempts to improve this by:

  * Ensuring that there are only two fundamentally different
    types of frames, a "standard" frame and a "typed" frame.
    Standard frames, as before, contain both a context and
    function pointer. Typed frames contain only a minimum
    of a smi marker in the position immediately below the fp
    where the context is in standard frames.
  * Only interpreted, full codegen, and optimized Crankshaft and
    TurboFan JavaScript frames use the "standard" format. All
    other frames use the type frame format with an explicit
    marker.
  * Typed frames can contain one or more values below the
    type marker. There is new magic macro machinery in
    frames.h that simplifies defining the offsets of these fields
    in typed frames.
  * A new flag in the CallDescriptor enables specifying whether
    a frame is a standard frame or a typed frame. Secondary
    register location spilling is now only enabled for standard
    frames.
  * A zillion places in the code have been updated to deal with
    the fact that most code stubs and internal frames use the
    typed frame format. This includes changes in the
    deoptimizer, debugger, and liveedit.
  * StandardFrameConstants::kMarkerOffset is deprecated,
    (CommonFrameConstants::kContextOrFrameTypeOffset
    and StandardFrameConstants::kFrameOffset are now used
    in its stead).

BUG=

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

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

Port 9dcd0857

Original commit message:
    Before this CL, various code stubs used different techniques
    for marking their frames to enable stack-crawling and other
    access to data in the frame. All of them were based on a abuse
    of the "standard" frame representation, e.g. storing the a
    context pointer immediately below the frame's fp, and a
    function pointer after that. Although functional, this approach
    tends to make stubs and builtins do an awkward, unnecessary
    dance to appear like standard frames, even if they have
    nothing to do with JavaScript execution.

    This CL attempts to improve this by:

    * Ensuring that there are only two fundamentally different
      types of frames, a "standard" frame and a "typed" frame.
      Standard frames, as before, contain both a context and
      function pointer. Typed frames contain only a minimum
      of a smi marker in the position immediately below the fp
      where the context is in standard frames.
    * Only interpreted, full codegen, and optimized Crankshaft and
      TurboFan JavaScript frames use the "standard" format. All
      other frames use the type frame format with an explicit
      marker.
    * Typed frames can contain one or more values below the
      type marker. There is new magic macro machinery in
      frames.h that simplifies defining the offsets of these fields
      in typed frames.
    * A new flag in the CallDescriptor enables specifying whether
      a frame is a standard frame or a typed frame. Secondary
      register location spilling is now only enabled for standard
      frames.
    * A zillion places in the code have been updated to deal with
      the fact that most code stubs and internal frames use the
      typed frame format. This includes changes in the
      deoptimizer, debugger, and liveedit.
    * StandardFrameConstants::kMarkerOffset is deprecated,
      (CommonFrameConstants::kContextOrFrameTypeOffset
      and StandardFrameConstants::kFrameOffset are now used
      in its stead).

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

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

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

R=titzer@chromium.org

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

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

I implemented I64ShrU and I64ShrS the same as I64Shl in https://codereview.chromium.org/1756863002

R=titzer@chromium.org

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

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

R=titzer@chromium.org

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

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

- Eliminate stubs with a variable number of arguments.
  (That only worked due to their very limited use. These
   stubs' interface descriptors were basically lying
   about their number of args, which will fail when used
   generically.)
- Fix all CallApi*Stubs' interface descriptors to no
  longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
  FunctionWithFixedArgs.
  (Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
  *ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
  parameters exceeds the supported number of args.

BUG=

Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
Cr-Commit-Position: refs/heads/master@{#34614}

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

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

Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of https://codereview.chromium.org/1748123003/ )

Reason for revert:
Breaks Chromium.

Original issue's description:
> Rework CallApi*Stubs.
>
> - Eliminate stubs with a variable number of arguments.
>   (That only worked due to their very limited use. These
>    stubs' interface descriptors were basically lying
>    about their number of args, which will fail when used
>    generically.)
> - Fix all CallApi*Stubs' interface descriptors to no
>   longer lie about their arguments.
> - Unify CallApi*Stub, for * in Function, Accessor,
>   FunctionWithFixedArgs.
>   (Since these are now all doing the same thing.)
> - Rename the unified stub (and interface descriptors) to
>   *ApiCallback*, since that's really what they're doing.
> - Refuse inlining an API callback if its number of
>   parameters exceeds the supported number of args.
>
> BUG=
>
> Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
> Cr-Commit-Position: refs/heads/master@{#34614}

TBR=danno@chromium.org,jkummerow@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

BUG=chromium:592341
LOG=n

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

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

- Eliminate stubs with a variable number of arguments.
  (That only worked due to their very limited use. These
   stubs' interface descriptors were basically lying
   about their number of args, which will fail when used
   generically.)
- Fix all CallApi*Stubs' interface descriptors to no
  longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
  FunctionWithFixedArgs.
  (Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
  *ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
  parameters exceeds the supported number of args.

BUG=

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

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

In case when F was called with incompatible number of arguments (and therefore
the arguments adator frame was created), F inlines a tail call of G which then
deopts the deoptimizer should also remove the arguments adaptor frame for F.

This CL adds required machinery to the deoptimizer.

BUG=v8:4698
LOG=N

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

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

After fixing the memory barrier for maps (https://codereview.chromium.org/1714513003), we are using a temp register for the map case. The temp register should not be aliased with the stored value (otherwise we perform the mem barrier check with a wrong value). This CL makes sure it is not aliased.

BUG=chromium:590074
LOG=n

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

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

This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

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

R=binji@chromium.org,dschuff@chromium.org
BUG=

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

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

This adds the number of properties to be expected within the boilerplate
object for object literals to the TurboFan IR. The reason is that this
length can no longer be easily inferred from just the constants array.
The length is potentially non-zero for empty object literals and might
also diverge in the presence of constant functions or duplicate property
names.

For future safety and for symmetry reasons, the same change was applied
to array literals as well, even though inferring the length from the
constant elements is still possible there.

R=verwaest@chromium.org
BUG=chromium:593008
LOG=n

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

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

  port 2aae579c (r34566)

  original commit message:
  In case when F tail calls G we should also remove the potential arguments adaptor frame for F.

  This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and ArchTailCallJSFunction)
  also drop arguments adaptor frame if it exists right before jumping to the target function.

BUG=

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

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

  port ddc626e1 (r34546)

  original commit message:
  I64Shl is lowered to a new turbofan operator, WasmWord64Shl. The new
  operator takes 3 inputs, the low-word input, the high-word input, and
  the shift, and produces 2 output, the low-word output and the high-word
  output.

  At the moment I implemented the lowering only for ia32, but I think the
  CL is already big enough. I will add the other platforms in separate
  CLs.

BUG=

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

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

Port 2aae579c

Original commit message:
    In case when F tail calls G we should also remove the potential arguments adaptor frame for F.

    This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and
    ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and
    ArchTailCallJSFunction) also drop arguments adaptor frame if it exists right before jumping
    to the target function.

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

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

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

Port ddc626e1

Original commit message:
    I64Shl is lowered to a new turbofan operator, WasmWord64Shl. The new
    operator takes 3 inputs, the low-word input, the high-word input, and
    the shift, and produces 2 output, the low-word output and the high-word
    output.

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

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

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

I removed some stale comments and added a missing unit test.

R=titzer@chromium.org

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

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

R=titzer@chromium.org

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

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

Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.

This CL attempts to improve this by:

* Ensuring that there are only two fundamentally different
  types of frames, a "standard" frame and a "typed" frame.
  Standard frames, as before, contain both a context and
  function pointer. Typed frames contain only a minimum
  of a smi marker in the position immediately below the fp
  where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
  TurboFan JavaScript frames use the "standard" format. All
  other frames use the type frame format with an explicit
  marker.
* Typed frames can contain one or more values below the
  type marker. There is new magic macro machinery in
  frames.h that simplifies defining the offsets of these fields
  in typed frames.
* A new flag in the CallDescriptor enables specifying whether
  a frame is a standard frame or a typed frame. Secondary
  register location spilling is now only enabled for standard
  frames.
* A zillion places in the code have been updated to deal with
  the fact that most code stubs and internal frames use the
  typed frame format. This includes changes in the
  deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
  (CommonFrameConstants::kContextOrFrameTypeOffset
  and StandardFrameConstants::kFrameOffset are now used
  in its stead).

LOG=N

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

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

In case when F tail calls G we should also remove the potential arguments adaptor frame for F.

This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and ArchTailCallJSFunction) also drop arguments adaptor frame if it exists right before jumping to the target function.

BUG=v8:4698
LOG=N

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

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

Local declarations were previously encoded as an optional set of
4 uint16 values as part of the function declaration. This CL
implements the current design of moving these declarations to
a list of pairs of (type, count) that is part of the body.

R=bradnelson@chromium.org,binji@chromium.org
BUG=

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

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

Implementation of https://codereview.chromium.org/1756863002 on arm.

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

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

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

I64Shl is lowered to a new turbofan operator, WasmWord64Shl. The new
operator takes 3 inputs, the low-word input, the high-word input, and
the shift, and produces 2 output, the low-word output and the high-word
output.

At the moment I implemented the lowering only for ia32, but I think the
CL is already big enough. I will add the other platforms in separate
CLs.

R=titzer@chromium.org

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

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

TestNotEqualsStrict is converted to a TestEqualsStrict and logical not
by the parser. Also, CompareIC does not have an implementation for
TestNotEqualsStrict. Hence, removing this bytecode.

BUG=v8:4280
LOG=N

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

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

BUG=

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

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

It benefits certain algorithms in register allocation to assume the input is
SSA - understanding that ResolvePhis in the regalloc pipeline lowers
phis, thus blurring the SSA invariant.

BUG=

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

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

It seems we produce both the usual add as well as the add with
overflow, when we should only generate the overflow variant. This
invalidates SSA assumptions in 2 tests (cctest/test-run-machops/RunInt32AddWithOverflowImm and
cctest/test-run-machops/RunInt64AddWithOverflowImm).

BUG=

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

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

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

On 32-bit systems FXXXConvertI64 instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameter is done in the
Int64Lowering.

R=titzer@chromium.org, yangguo@chromium.org

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

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

Add StringLessThanStub, StringLessThanOrEqualStub, StringGreaterThanStub
and StringGreaterThanOrEqualStub, based on the CodeStubAssembler, and
hook them up with TurboFan (and Ignition). The stubs are currently
essentially comparable with the StringCompareStub, which is now
obsolete. We can later extend these stubs to cover more interesting
cases (i.e. two byte sequential string comparisons, etc.).

R=epertoso@chromium.org

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

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

Frames entering of inside wasm don't have a function or context argument.
Adding distinct wasm frame and function types to express this.

Fixes a GC issue on several embenchen wasm tests, reenabling them.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/wasm/embenchen
R=titzer@chromium.org,aseemgarg@chromium.org,jfb@chromium.org,yangguo@chromium.org
LOG=N

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

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

Do not emit 2 operations for int64 add with overflow.

BUG=

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

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

This adds new code stubs for abstract relational comparison,
namely LessThanStub, LessThanOrEqualStub, GreaterThanStub and
GreaterThanOrEqualStub, and hooks them up for Ignition and TurboFan.
These stubs implement the full compare operation without any
unpredictable bailouts. Currently they still go to C++ for string
comparisons, and also use the %ToPrimitive_Number runtime entry, as
we still lack a stub for the ToPrimitive operation. These issues
will be addressed separately in follow-up CLs.

Drive-by-fix: Add support for deferred code in the RawMachineAssembler
and CodeStubAssembler. A block can be marked as deferred by marking its
Label as deferred, which will then make the register allocator penalize
this block and prefer better register assignments for the other blocks.

R=epertoso@chromium.org

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

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