1. 25 May, 2020 5 commits
  2. 22 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Generate better code when using `&` operator on bitfields · 98438d86
      Seth Brenith authored
      Sometimes CSA code carefully constructs a mask to check several
      bitfields at once. Thus far, such a check has been very awkward to write
      in Torque. This change adds a way to do so, using the
      non-short-circuiting binary `&` operator. So now you can write an
      expression that depends on several bitfields from a bitfield struct,
      like `x.a == 5 & x.b & !x.c & x.d == 2` (assuming b is a one-bit value),
      and it will be reduced to a single mask and equality check. To
      demonstrate a usage of this new reduction, this change ports the trivial
      macro IsSimpleObjectMap to Torque. I manually verified that the
      generated code for the builtin SetDataProperties, which uses that macro,
      is unchanged.
      
      Bug: v8:7793
      Change-Id: I4a23e0005d738a6699ea0f2a63f9fd67b01e7026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183276
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67948}
      98438d86
  3. 21 May, 2020 10 commits
  4. 20 May, 2020 22 commits
  5. 19 May, 2020 2 commits
    • Zhi An Ng's avatar
      Revert "[wasm-simd][liftoff][x64][ia32] Implement load extend" · 7bd682c9
      Zhi An Ng authored
      This reverts commit dd19a400.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/30448?
      
      Original change's description:
      > [wasm-simd][liftoff][x64][ia32] Implement load extend
      > 
      > The operations are implemented:
      > 
      > - i16x8.load8x8_s
      > - i16x8.load8x8_u
      > - i32x4.load16x4_s
      > - i32x4.load16x4_u
      > - i64x2.load32x2_s
      > - i64x2.load32x2_u
      > 
      > on x64 and i32. The rest of the arch currently bail out, and will be
      > implemented in subsequent patches.
      > 
      > The liftoff-compiler.cc code looks very similar to the one for LoadMem,
      > the only difference is special handling of kSplat v.s. kExtend. kExtend
      > always loads 8 bytes, so the bounds check and tracing is different.
      > Compared to LoadMem there is less need for pinning, since the result is
      > always going to be in a SIMD/FP register, which is different from the
      > index/addr register.
      > 
      > The enum LoadTransformationKind was moved from
      > function-body-decoder-impl.h to function-body-decoder.h so that no
      > unncessary header file inclusions were needed to liftoff, and also it's
      > a better place for it to live.
      > 
      > Bug: v8:9909
      > Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67914}
      
      TBR=clemensb@chromium.org,zhin@chromium.org
      
      Change-Id: I2af6dfe6cd163d0dbc9f3a5ad4bfc5e622e76b63
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9909
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207665Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67915}
      7bd682c9
    • Ng Zhi An's avatar
      [wasm-simd][liftoff][x64][ia32] Implement load extend · dd19a400
      Ng Zhi An authored
      The operations are implemented:
      
      - i16x8.load8x8_s
      - i16x8.load8x8_u
      - i32x4.load16x4_s
      - i32x4.load16x4_u
      - i64x2.load32x2_s
      - i64x2.load32x2_u
      
      on x64 and i32. The rest of the arch currently bail out, and will be
      implemented in subsequent patches.
      
      The liftoff-compiler.cc code looks very similar to the one for LoadMem,
      the only difference is special handling of kSplat v.s. kExtend. kExtend
      always loads 8 bytes, so the bounds check and tracing is different.
      Compared to LoadMem there is less need for pinning, since the result is
      always going to be in a SIMD/FP register, which is different from the
      index/addr register.
      
      The enum LoadTransformationKind was moved from
      function-body-decoder-impl.h to function-body-decoder.h so that no
      unncessary header file inclusions were needed to liftoff, and also it's
      a better place for it to live.
      
      Bug: v8:9909
      Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67914}
      dd19a400