This refines 6382a610 -- as we still
require clean up of the uint index register.

TEST=mjsunit/asm/float32array-negative-offset
R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=

Conflicts:
	src/compiler/s390/code-generator-s390.cc

Review-Url: https://codereview.chromium.org/1921073003
Cr-Commit-Position: refs/heads/master@{#35879}

BUG=chromium:607115
LOG=n

Review-Url: https://codereview.chromium.org/1928903002
Cr-Commit-Position: refs/heads/master@{#35855}

Port 0231a7ef

Original commit message:

    This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
    trick that was used in the MachineOperatorReducer to combine the
    ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
    doing that later, we can just introduce the proper operator during the
    representation selection directly.

    Also separate the TruncateFloat64ToInt32 machine operator, which had two
    different meanings depending on a flag (either JavaScript truncation or
    C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
    represents the JavaScript truncation (implemented via TruncateDoubleToI
    macro + code stub) and the RoundFloat64ToInt32, which implements the C++
    round towards zero operation (in the same style as the other WebAssembly
    driven Round* machine operators).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

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

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

TEST=cctest/test-run-load-store/*
R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=

S390: [interpreter] Heal closures when bytecode array is gone.

Port 5c8609de

Original commit message:

    This ensures the InterpreterEntryTrampoline heals code entry fields
    inside closures when being called without a valid bytecode array. This
    is preparatory work to allow removal of bytecode when switching some
    functions to other types of code.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4280
LOG=N

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

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

This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.

Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).

R=jarin@chromium.org

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

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

Port 81a1530e

Original commit message:

    Before frame elision, we finalized the frame shape when assembling the
    prologue, which is also when we prepared the frame (saving sp, etc).

    The frame finalization only needs to happen once, and happens to be
    actually a set of idempotent operations. With frame elision, the logic for
    frame finalization was happening every time we constructed the frame.
    Albeit idempotent operations, the code would become hard to maintain.

    This change separates frame shape finalization from frame
    construction. When constructing the CodeGenerator, we finalize the
    frame. Subsequent access is to a const Frame*.

    Also renamed AssemblePrologue to AssembleConstructFrame, as
    suggested in the frame elision CR.

    Separating frame setup gave the opportunity to do away with
    architecture-independent frame aligning (which is something just arm64
    cares about), and also with stack pointer setup (also arm64). Both of
    these happen now at frame finalization on arm64.

R=mtrofin@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

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

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

Port d412cfa2

Original commit message:
    [Atomics] Remove Atomics code stubs; use TF ops

    Reland of (https://codereview.chromium.org/1891033002)

    This is a much cleaner solution, which won't require nearly as much
    architecture-specific code. Thanks bmeurer@!

R=binji@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4614
LOG=N

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

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

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, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=v8:4280
LOG=N

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

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

port 52148c41

Original Commit Message:
    Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates.

R=gdeepti@google.com, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com, mbrandy@us.ibm.com
BUG=

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

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

Debug asserts in code-generator-s390.cc are in place to ensure that overflow is only set when dealing with a sub or add opcode. However, the check only looked for kS390_Add/SubWithOverflow32, not kS390_Add/Sub which also sets overflow. This CL adds the second case to this assert check.

R=michael_dawson@ca.ibm.com,jyan@ca.ibm.com,mtbrandyberry@ca.ibm.com,joransiu@ca.ibm.com

BUG=

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

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

The existing FloatFloor/Ceiling functions had an issue with handling
Number.MIN_VALUE (0x1 ==> 5e-324), and would incorrectly return
MIN_VALUE instead of 0/1.  Simplify the entire sequence by using the
available hardware instruction with the appropriate rounding mode
(POS_INF for Ceiling, NEG_INF for Floor).

Add missing FIEBRA/FIDBRA cases to disassembler.

R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

port ac7f0e2b

Original Commit Message:
   *) 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, ahaas@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port 53d51c52

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.

R=mtrofin@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, rmcilroy@chromium.org
BUG=v8:4533
LOG=N

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

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

port 40bdbef9

 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.

R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=

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

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

Properly implement Rotate Right sequence for S390, to use the 64-bit
RLLG instruction.

R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

The CodeGenerator sequence for Mod64/ModU64 is incorrectly using
32-bit operations.  Fix Mod64/ModU64 to use 64-bit divides to calculate
the remainder.

Fix disassembly for DLR, which was reading the wrong bits for the two
register operands.

R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

The CodeGenerator sequence for kS390_Div64 was incorrectly defaulting
to the 32-bit divide sequence.  That case has been fixed to use the
proper 64-bit divide (DSGR).

Fix bug in DLGR simulation where the register number was being used as
operands instead of the values in those registers.

R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

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

    Port 33c08596

    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.

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

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

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

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.

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

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

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

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/1802343002

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

Upstream S390 platform specific code to latest lkgr from the past 2 weeks.

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/1799893002

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

BUG=chromium:582702
LOG=N

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

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

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}

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}