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}

  port f954934d (r35140)

  original commit message:

BUG=

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

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

  port 53d51c52 (r35139)

  original commit message:
  Removed Frame::needs_frame and the function-wide logic using it in
  favor of FrameAccessState::has_frame, which can be set on a more
  granular level, and driving it block by block.

BUG=

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

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

*) For all tests the input validation was incorrect, i.e. some values
were considered invalid although they were valid. The problem was that
values which are outside int range can get in range through truncation.

*) Removed an assertion in the x64 code generation of
TruncateFloat64ToUint32 which trapped on negative inputs.

*) Introduced a new TF operator TruncateFloat32ToUint32 which does
the same as ChangeFloat32ToUint32 but does not trap on negative inputs.

R=titzer@chromium.org

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

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

  port 40bdbef9 (r35131)

  original commit message:
  Int64Mul is lowered to a new turbofan operator, Int32MulPair. The new
  operator takes 4 inputs an generates 2 outputs. The inputs are the low
  word of the left input, high word of the left input, the low word of the
  right input, and high word of the right input. The ouputs are the low
  and high word of the result of the multiplication.

BUG=

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

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

Int64Mul is lowered to a new turbofan operator, Int32MulPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the multiplication.

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

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

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

  The CL #34967 (https://codereview.chromium.org/1804243003) and CL #35045 (https://codereview.chromium.org/1825333004)
  exposed one hidden bug in x87 turbofan code generation for Float32ToFloat64.

  This CL fixed this bug.

BUG=

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

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

  port 1da4b88e (r34978)

  original commit message:
  The idiv instruction has 2 registers as output. This needs to be
  modeled so that the move optimizer won't incorrectly elide away
  moves.

BUG=

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

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

  port 33c08596 (r34808)

  original commit message:
  Int64Sub is lowered to a new turbofan operator, Int32SubPair. The new
  operator takes 4 inputs an generates 2 outputs. The inputs are the low
  word of the left input, high word of the left input, the low word of the
  right input, and high word of the right input. The ouputs are the low
  and high word of the result of the subtraction.

  The implementation is very similar to the implementation of Int64Add.

  @v8-arm-ports: please take a careful look at the implementation of sbc
  in the simulator

BUG=

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

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

Int64Sub is lowered to a new turbofan operator, Int32SubPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the subtraction.

The implementation is very similar to the implementation of Int64Add.

@v8-arm-ports: please take a careful look at the implementation of sbc
in the simulator.

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

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

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

  port 1b230799 (r34747)

  original commit message:
  Int64Add is lowered to a new turbofan operator, Int32AddPair. The new
  operator takes 4 inputs an generates 2 outputs. The inputs are the low
  word of the left input, high word of the left input, the low word of the
  right input, and high word of the right input. The ouputs are the low
  and high word of the result of the addition.

BUG=

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

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

Int64Add is lowered to a new turbofan operator, Int32AddPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the addition.

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

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

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

BUG=chromium:582702
LOG=N

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

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

  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}

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}

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}

  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}

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}

  port c129aa4d (r34239)

  original commit message:
  These macro operators represent a conditional eager deoptimization exit
  without explicit branching, which greatly reduces overhead of both
  scheduling and register allocation, and thereby greatly reduces overall
  compilation time, esp. when there are a lot of eager deoptimization
  exits.

BUG=

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

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

  port 0e43ff56 (r34187)

  original commit message:
  The InstructionSelector now associates an effect level to every node in a block.

  The effect level of a node is the number of non-eliminatable nodes encountered from the beginning of the block to the node itself.

  With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand if all of the following conditions hold:

  1. The only use of the load is in a 32 or 64 bit word comparison.
  2. The user node and the load node belong to the same block.
  3. The values of the operands have the same size (i.e., no need to zero-extend or sign-extend the result of the load).

BUG=

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

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

This picks the record-write stub depending on the correct remembered set
action parameter. For values known to be maps we can guarantee that they
never reside in new-space, hence store buffer recording can be skipped.

R=bmeurer@chromium.org

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

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

We cannot omit flag check with kPointersToHereAreInterestingMask for maps because incremental marker dynamically sets and clears the flag.

BUG=chromium:587004
LOG=NO

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

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

  port 55071954 (r34114)

  original commit message:
  Frame slots indexes numbers are used more consistently for
  computation in both TurboFan and Crankshaft. Specifically,
  Crankshaft now uses frame slot indexes in LChunk, removing
  the need for some special-case maths when building the
  deoptimization translation table.

BUG=

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

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

  Unstructured control flow caused by excpetion leads to a wrong x87 FPU stack
  state in TurboFan's exception handler.

  This patch is to reset the x87 FPU stack state when calling the TurboFan's exception
  handler from the CEntryStub.

BUG=

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

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

Adds kSimd128 to MachineRepresentation.
Adds a Simd128Register concept that's platform independent.
Adds UntaggedSimd128 to types.h.

LOG=N
BUG=v8:4124

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

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

  port fd8fd05c (r34014)

  original commit message:
  This functionality is useful for stubs that need to walk the stack. The new
  machine operator, LoadParentFramePointer dosn't force the currently compiling
  method to have a frame in contrast to LoadFramePointer. Instead, it adapts
  accordingly when frame elision is possible, making efficient stack walks
  possible without incurring a performance penalty for small stubs that can
  benefit from frame elision.

BUG=

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

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

Let me know if this is not the right approach

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

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

The LazyBailout operator (modelled as a nop-call) was introduced for
placing a deoptimization point into exception handlers. Now that we are
no longer re-entering lazy deoptimized code, the support can be removed.

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

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

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

Initially we were unable to address certain stack slots in the callee
part of the frame, including the function marker, therefore we had to
hack a reload of the function register into the OSR prologue. Now that
we are able to address all stack slots, we no longer need this hack.

R=jarin@chromium.org

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

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

  port 2166bd8c (r33797)

  original commit message:

BUG=

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

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

  port 187b3f28 (r33796)

  original commit message:

BUG=

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

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

BUG=

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

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

BUG=

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

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

  Unstructured control flow caused by excpetion handling leads to a wrong x87 stack
  state. This patch is to reset the x87 state at the hanlder entry point.

  Thanks for help from weiliang.lin@intel.com.

BUG=

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

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

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}