1. 24 Jul, 2020 1 commit
  2. 22 Jun, 2020 1 commit
  3. 18 Jun, 2020 1 commit
  4. 16 Jun, 2020 1 commit
  5. 10 Jun, 2020 1 commit
  6. 09 Jun, 2020 1 commit
  7. 03 Jun, 2020 1 commit
  8. 02 Jun, 2020 2 commits
  9. 21 May, 2020 1 commit
  10. 13 May, 2020 1 commit
  11. 01 May, 2020 1 commit
  12. 30 Apr, 2020 1 commit
  13. 27 Apr, 2020 1 commit
    • Ng Zhi An's avatar
      Reland "[arm] Change fp_fixed registers to be allocatable registers" · 610f72a5
      Ng Zhi An authored
      This relands commit 1a38573f.
      
      The original change used a sequence of instruction in the test that
      could not be scalar lowered properly.
      
      Original change's description:
      > [arm] Change fp_fixed registers to be allocatable registers
      >
      > fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
      > need to be allocatable, so that they can be correctly marked as fixed
      > and spilled as required. The previous value of fp_fixed2, d29, is not in
      > the list of allocatable double registers, and not marked as fixed
      > appropriately.
      >
      > One fix could be to extend the list of allocatable double registers, but
      > there is a comment there saying that the list is kept even-length to
      > make stack alignment easier. So rather than messing with that, we
      > instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
      > the only user, this is a simpler change.
      >
      > Bug: chromium:1070078
      > Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67372}
      
      Bug: chromium:1070078
      Change-Id: I02bb4b3ad03817318cbd0ee706c5ef4f20c845ba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165867Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67406}
      610f72a5
  14. 24 Apr, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[arm] Change fp_fixed registers to be allocatable registers" · 1a38573f
      Francis McCabe authored
      This reverts commit 390ed4b9.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36714?
      
      
      Original change's description:
      > [arm] Change fp_fixed registers to be allocatable registers
      > 
      > fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
      > need to be allocatable, so that they can be correctly marked as fixed
      > and spilled as required. The previous value of fp_fixed2, d29, is not in
      > the list of allocatable double registers, and not marked as fixed
      > appropriately.
      > 
      > One fix could be to extend the list of allocatable double registers, but
      > there is a comment there saying that the list is kept even-length to
      > make stack alignment easier. So rather than messing with that, we
      > instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
      > the only user, this is a simpler change.
      > 
      > Bug: chromium:1070078
      > Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67372}
      
      TBR=gdeepti@chromium.org,zhin@chromium.org,thibaudm@chromium.org
      
      Change-Id: I00b4b34771b5832cc3d5fe6eac7aac506ec82d50
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1070078
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165865Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67375}
      1a38573f
    • Ng Zhi An's avatar
      [arm] Change fp_fixed registers to be allocatable registers · 390ed4b9
      Ng Zhi An authored
      fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
      need to be allocatable, so that they can be correctly marked as fixed
      and spilled as required. The previous value of fp_fixed2, d29, is not in
      the list of allocatable double registers, and not marked as fixed
      appropriately.
      
      One fix could be to extend the list of allocatable double registers, but
      there is a comment there saying that the list is kept even-length to
      make stack alignment easier. So rather than messing with that, we
      instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
      the only user, this is a simpler change.
      
      Bug: chromium:1070078
      Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67372}
      390ed4b9
  15. 16 Apr, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm] Fix wasm decoder for multi-byte opcodes · b48b82e7
      Ng Zhi An authored
      SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
      were decoding this incorrectly as a fixed uint8. This fixes the decoder
      to properly handle multi bytes.
      
      In some cases, the multi byte logic is applied to all prefixed opcodes.
      This is not a problem, since for values < 0x80, the LEB encoding is a
      single byte, and decodes to the same int. If the prefix opcode has
      instructions with index >= 0x80, it would be required to be LEB128
      encoded anyway.
      
      There are a bunch of trivial changes to test-run-wasm-simd, to change
      the macro from BUILD to BUILD_V, the former only works for single byte
      opcodes, the latter is a new template-based macro that correct handles
      multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
      which builds its own sequence of bytes without using the BUILD macro.
      
      Bug: v8:10258
      Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67186}
      b48b82e7
  16. 06 Apr, 2020 1 commit
  17. 03 Apr, 2020 2 commits
  18. 23 Mar, 2020 3 commits
  19. 28 Feb, 2020 1 commit
  20. 26 Feb, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd] Fix OpcodeLength of load splat/extend ops · a67a16aa
      Ng Zhi An authored
      Move load splat and load extend ops into the list of SIMD memory
      opcodes, since they similarly take an i32 and an memarg. This fixes the
      OpcodeLength calculation in function-body-decoder-impl.h.
      
      And in turn, fixes the mjsunit test code that the fuzzer generates. See
      the regress-1055692.js file for the weird S8x16LoadSplat followed by 2
      kExprUnreachable, where the kExprUnreachable really is a memarg
      {0x0, 0x0}. This bug was caught by the fuzzer, and that was the
      generated test (with small fixes to add kExprDrop), so leaving it as it
      is.
      
      Bug: chromium:1055692
      Change-Id: I743b6beb82350b5fea22c8dd10b546a02741cfed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071401Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66439}
      a67a16aa
  21. 25 Feb, 2020 1 commit
    • Ng Zhi An's avatar
      Reland "[liftoff] Check fp_pair when looking up register for reuse" · 0d0d38fe
      Ng Zhi An authored
      This is a reland of 548fda4a
      
      regress-1054466 is modified to not use 64x2 operations, since that was
      causing problems on noavx/nosse builds, which requires scalar lowering,
      and scalar lowering for 64x2 ops is not implemented.
      
      Original change's description:
      > [liftoff] Check fp_pair when looking up register for reuse
      >
      > Given two registers that are both not gp_pair, one could be an fp_pair,
      > and the other not, and we will incorrect call == on them. The current
      > check needs to be expanded to check that both registers are fp_pair.
      >
      > Bug: chromium:1054466
      > Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66402}
      
      Bug: chromium:1054466
      Change-Id: If88f1ff2fb17aaa3727758cda5b368be1c6d9bd6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071396Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66423}
      0d0d38fe
  22. 24 Feb, 2020 2 commits
  23. 17 Feb, 2020 1 commit
  24. 15 Jan, 2020 2 commits
  25. 10 Jan, 2020 1 commit
  26. 09 Jan, 2020 1 commit
  27. 14 Nov, 2019 1 commit
  28. 13 Nov, 2019 2 commits
  29. 16 Oct, 2019 1 commit
  30. 11 Oct, 2019 1 commit
  31. 08 Oct, 2019 2 commits