Skip to content

V
V8
Switch branch/tag
  1. 25 Mar, 2021 4 commits
  3. 24 Mar, 2021 2 commits
  5. 23 Mar, 2021 10 commits
  7. 22 Mar, 2021 8 commits
  9. 19 Mar, 2021 9 commits
  11. 18 Mar, 2021 6 commits
    • Milad Fa's avatar
      PPC/s390: [wasm-simd] Canonicalize shuffles when creating TurboFan graph · d95b1645
      Milad Fa authored 
      Port d16eefe0

Original Commit Message:

    We currently canonicalize shuffles in the architecture specific
    instruction selector. This has the drawback that if we want to pattern
    match on nodes that have a shuffle as input, they need to individually
    canonicalize the shuffle. There can also be a subtle bug if we
    canonicalize the same shuffle node twice (see bug for details).

    This moves the canonicalization to "construction time", in
    wasm-compiler, when building the graph. As such, any pattern matches in
    instruction-selector will only need to deal with canonicalized shuffles.

    We introduce a new kind of parameter for shuffle nodes,
    ShuffleParameter, to store the 16 bytes plus a bool indicating if this
    is a swizzle. A swizzle essentially: inputs to the shuffle are the same
    or all indices only touch 1 input. We calculate this when
    canonicalizing, so store this bit of information inside of the node's
    parameter.

    We update the tests in x64 to handle special cases where, even though
    the node's inputs are not swapped (due to canonicalization), they need
    to be swapped for the specific instruction selected (e.g. palignr). The
    test data also contains canonicalized shuffles, so we have to manually
    canonicalize them.

R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: I9872fcdaa06739c8972f02d81e77bcbf372126c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773138Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73512}
      d95b1645
    • Thibaud Michaud's avatar
      [regalloc] Fix slot requirement for live ranges defined by a const · 0ee6f90a
      Thibaud Michaud authored 
      Live ranges defined by a constant operand normally don't require a spill
slot since they can just rematerialize the value from the constant. In
the attached issue however, deoptimization adds an explicit slot
requirement for a range that is defined by a constant operand. This case
is not expected in the register allocator and we eventually hit a
DCHECK.

This fix allocates a new stack slot during the MeetRegisterConstraints
and adds the missing gap move.

Drive-by: remove dead method LiveRange::NextSlotPosition.

R=sigurds@chromium.org
CC=​nicohartmann@chromium.org

Bug: chromium:1146880
Change-Id: I08fbb890f2f3d9574196989cf3e5ef6232433484
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563689Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73510}
      0ee6f90a
    • Ross McIlroy's avatar
      [Turboprop] Remove DecompressionOptimization phase from TurboProp. · 0cfeb2c0
      Ross McIlroy authored 
      Reduces the overhead of mid-tier optimization without much impact on
mid-tier generated code performance.

BUG=v8:9684

Change-Id: I81889049f718ec2b18a805b11aab119754466c95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772611
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73509}
      0cfeb2c0
    • Ross McIlroy's avatar
      [Turboprop] Avoid calling RepresentationFor in mid-tier allocator. · dcb0d4a6
      Ross McIlroy authored 
      RepresentationFor is quite hot in MidTierAllocator profiles. To
optimize this, instead stash the representation in the
VirtualRegisterData and pass that about consistently instead of
passing the virtual_register int and having to retrieve both
representation and VirtualRegisterData for the vreg multiple times.

This improves mid-tier allocation time by ~8% on Octane benchmarks.

BUG=v8:9684

Change-Id: Ied01fbdab013c278da022d1df321b08fbfc68a4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2768618Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73508}
      dcb0d4a6
    • Georgia Kouveli's avatar
      [cfi][arm64] Change OSR entry use of LR. · 9a97c863
      Georgia Kouveli authored 
      The previous uses of LR here allowed overwriting it with arbitrary addresses
that aren't signed. Change this so we never return to an arbitrary LR.

This makes a difference even when we replace the RET with a BR, because BR is
constrained by BTI, whereas RET isn't.

Bug: v8:10026
Change-Id: Ibbf326ccf0cf32f6d9541c7a82108dc0373827df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2767015Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#73507}
      9a97c863
    • Manos Koukoutos's avatar
      Revert "[turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer" · f4473d98
      Manos Koukoutos authored 
      This reverts commit a3b1233e.

Reason for revert: This approach has multiple issues and we have to reconsider it.

Original change's description:
> [turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer
>
> Bug: v8:11510
> Change-Id: I1e8fcb54444e494c7d765ad556d09d954441361f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752876
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73468}

Bug: v8:11510
Change-Id: Id35bc4ebcb45a617f61993d857ad2291b0287ad6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772600
Auto-Submit: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73502}
      f4473d98
  13. 17 Mar, 2021 1 commit
    • Ng Zhi An's avatar
      [wasm-simd] Canonicalize shuffles when creating TurboFan graph · d16eefe0
      Ng Zhi An authored 
      We currently canonicalize shuffles in the architecture specific
instruction selector. This has the drawback that if we want to pattern
match on nodes that have a shuffle as input, they need to individually
canonicalize the shuffle. There can also be a subtle bug if we
canonicalize the same shuffle node twice (see bug for details).

This moves the canonicalization to "construction time", in
wasm-compiler, when building the graph. As such, any pattern matches in
instruction-selector will only need to deal with canonicalized shuffles.

We introduce a new kind of parameter for shuffle nodes,
ShuffleParameter, to store the 16 bytes plus a bool indicating if this
is a swizzle. A swizzle essentially: inputs to the shuffle are the same
or all indices only touch 1 input. We calculate this when
canonicalizing, so store this bit of information inside of the node's
parameter.

We update the tests in x64 to handle special cases where, even though
the node's inputs are not swapped (due to canonicalization), they need
to be swapped for the specific instruction selected (e.g. palignr). The
test data also contains canonicalized shuffles, so we have to manually
canonicalize them.

Bug: v8:11542
Change-Id: I4e78082267bd03d6caedf43d68d81ef3f5f364a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2762420Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73495}
      d16eefe0