1. 10 Jun, 2021 1 commit
  2. 26 May, 2021 1 commit
  3. 13 May, 2021 1 commit
  4. 22 Apr, 2021 1 commit
  5. 21 Apr, 2021 1 commit
  6. 17 Apr, 2021 1 commit
    • Ng Zhi An's avatar
      Revert "[wasm-simd] Canonicalize shuffles when creating TurboFan graph" · ede5e814
      Ng Zhi An authored
      This reverts commit d16eefe0.
      
      It is not correct to check for node equality during the graph
      construction phase, because we can have optimizations that will combine
      same nodes. So it can happen that in wasm-compiler, the inputs to
      shuffle are not the same, so we canonicalize using that knowledge that
      it will not be the same, and allow indices > 15. But later we can have
      optimizations that combine the 2 inputs (e.g. splat of the same
      constants), and the instruction selector will see that the input nodes
      are the same.
      
      Bug: v8:11542,chromium:1199662
      Change-Id: I21c175f4707708038710147f64d687d1b14c6ecc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829986
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74017}
      ede5e814
  7. 13 Apr, 2021 2 commits
  8. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored
      This CL adds features to pack/unpack map words.
      
      Currently V8 cannot store extra metadata in object headers -- because V8
      objects do not have a proper header, but only a map pointer at the start
      of the object. To store per-object metadata like marking data, a side
      table is required as the per-object metadata storage.
      
      This CL enables V8 to use higher unused bits in a 64-bit map word as
      per-object metadata storage. Map pointer stores come with an extra step
      to encode the metadata into the pointer (we call it "map packing").
      Map pointer loads will also remove the metadata bits as well (we call it
      "map packing").
      
      Since the map word is no longer a valid pointer after packing, we also
      change the tag of the packed map word to make it looks like a Smi. This
      helps various GC and barrier code to correctly skip them instead of
      blindly dereferencing this invalid pointer.
      
      A ninja flag `v8_enable_map_packing` is provided to turn this
      map-packing feature on and off. It is disabled by default.
      
      * Only works on x64 platform, with `v8_enable_pointer_compression`
        set to `false`
      
      Bug: v8:11624
      Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  9. 29 Mar, 2021 1 commit
  10. 23 Mar, 2021 1 commit
    • Manos Koukoutos's avatar
      [turbofan] Introduce LoadImmutable, use it in wasm compiler · f6ee9ed0
      Manos Koukoutos authored
      LoadImmutable represents a load from a position in memory that is known
      to be immutable, e.g. an immutable IsolateRoot or an immutable field of
      a WasmInstanceObject. Because the returned value cannot change through
      the execution of a function, LoadImmutable is a pure operator and does
      not have effect or control edges.
      This will allow more aggressive optimizations of loads of fields of
      the Isolate and Instance that are known to be immutable.
      Requires that the memory in question has been initialized at function
      start even through inlining.
      
      Note: We may reconsider this approach once we have escape analysis for
      wasm, and replace it with immutable load/initialize operators that live
      inside the effect chain and are less restriced.
      
      Bug: v8:11510
      Change-Id: I5e8e4f27d7008f39f01175ffa95a9c531ba63e66
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775568Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73594}
      f6ee9ed0
  11. 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
  12. 10 Mar, 2021 1 commit
  13. 09 Mar, 2021 1 commit
  14. 06 Mar, 2021 1 commit
  15. 05 Mar, 2021 1 commit
  16. 26 Feb, 2021 1 commit
  17. 24 Feb, 2021 1 commit
  18. 23 Feb, 2021 1 commit
  19. 22 Feb, 2021 2 commits
  20. 19 Feb, 2021 1 commit
  21. 18 Feb, 2021 1 commit
  22. 04 Feb, 2021 1 commit
  23. 02 Feb, 2021 1 commit
  24. 29 Jan, 2021 1 commit
  25. 27 Jan, 2021 1 commit
  26. 18 Jan, 2021 1 commit
  27. 15 Jan, 2021 1 commit
  28. 14 Jan, 2021 1 commit
  29. 12 Jan, 2021 1 commit
  30. 21 Dec, 2020 1 commit
  31. 14 Dec, 2020 1 commit
  32. 10 Dec, 2020 1 commit
  33. 01 Dec, 2020 3 commits
  34. 17 Nov, 2020 1 commit
  35. 12 Nov, 2020 1 commit
    • Pierre Langlois's avatar
      [heap] Do not use V8_LIKELY on FLAG_disable_write_barriers. · 4a89c018
      Pierre Langlois authored
      FLAG_disable_write_barriers is a constexpr so the V8_LIKELY macro isn't
      necessary. Interestingly, it can also cause clang to warn that the code
      is unreachable, whereas without `__builtin_expect()` the compiler
      doesn't mind. See for example:
      
      ```
      constexpr bool kNo = false;
      
      void warns() {
        if (__builtin_expect(kNo, 0)) {
          int a = 42;
        }
      }
      
      void does_not_warn() {
        if (kNo) {
          int a = 42;
        }
      }
      ```
      
      Compiling V8 for arm64 with both `v8_disable_write_barriers = true` and
      `v8_enable_pointer_compression = false` would trigger this warning.
      
      Bug: v8:9533
      Change-Id: Id2ae156d60217007bb9ebf50628e8908e0193d05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534811Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#71157}
      4a89c018
  36. 03 Nov, 2020 1 commit