1. 25 Feb, 2017 1 commit
  2. 21 Feb, 2017 1 commit
    • bbudge's avatar
      [V8] Implement SIMD Boolean vector types to allow mask registers. · 9fe0b4c7
      bbudge authored
      - Adds new machine types SimdBool4/8/16 for the different boolean vector types.
      - Adds a kSimdMaskRegisters flag for each platform. These are all false for now.
      - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle
        opcodes from the Boolean types. These are unlikely to be well supported natively,
        and can be synthesized using Select.
      - Changes the signature of Relational opcodes to return boolean vectors.
      - Changes the signature of Select opcodes to take boolean vectors.
      - Updates the ARM implementation of Relational and Select opcodes.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2700813002
      Cr-Commit-Position: refs/heads/master@{#43348}
      9fe0b4c7
  3. 16 Feb, 2017 1 commit
    • rossberg's avatar
      [wasm] Inspect right control frames for unreachable flag · e2b83fbb
      rossberg authored
      We were looking at the unreachable flag or stack_depth of the target frame
      instead of the current one in a couple of places (most notably BreakTo).
      This change fixes these bugs and makes us pass the latest spec tests for
      br_table validation. Also need to ensure that br_table targets have consistent
      types, which is not implied if the stack is polymorphic.
      
      R=titzer@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2696813002
      Cr-Commit-Position: refs/heads/master@{#43250}
      e2b83fbb
  4. 13 Feb, 2017 1 commit
  5. 10 Feb, 2017 1 commit
  6. 07 Feb, 2017 1 commit
  7. 02 Feb, 2017 1 commit
  8. 26 Jan, 2017 1 commit
  9. 25 Jan, 2017 1 commit
  10. 20 Jan, 2017 2 commits
  11. 19 Jan, 2017 1 commit
  12. 18 Jan, 2017 2 commits
  13. 15 Jan, 2017 1 commit
  14. 13 Jan, 2017 2 commits
  15. 12 Jan, 2017 4 commits
  16. 09 Jan, 2017 2 commits
  17. 06 Jan, 2017 2 commits
  18. 04 Jan, 2017 1 commit
  19. 21 Dec, 2016 3 commits
  20. 14 Dec, 2016 1 commit
  21. 06 Dec, 2016 1 commit
  22. 02 Dec, 2016 1 commit
  23. 01 Dec, 2016 1 commit
    • clemensh's avatar
      [base] Define CHECK comparison for signed vs. unsigned · db0c86fa
      clemensh authored
      The current CHECK/DCHECK implementation fails statically if a signed
      value is compared against an unsigned value. The common solution is to
      cast on each caller, which is tedious and error-prone (might hide bugs).
      This CL implements signed vs. unsigned comparisons by executing up to
      two comparisons. For example, if i is int32_t and u is uint_32_t, a
      DCHECK_LE(i, u) would create the check
      i <= 0 || static_cast<uint32_t>(i) <= u.
      For checks against constants, at least one of the checks can be removed
      by compiler optimizations.
      
      The tradeoff we have to make is to sometimes silently execute an
      additional comparison. And we increase code complexity of course, even
      though the usage is just as easy (or even easier) as before.
      
      The compile time impact seems to be minimal:
      I ran 3 full compilations for Optdebug on my local machine, one time on
      the current ToT, one time with this CL plus http://crrev.com/2524093002.
      Before: 143.72 +- 1.21 seconds
      Now: 144.18 +- 0.67 seconds
      
      In order to check that the new comparisons are working, I refactored
      some DCHECKs in wasm to use the new magic, and added unit test cases.
      
      R=ishell@chromium.org, titzer@chromium.org
      CC=ahaas@chromium.org, bmeurer@chromium.org
      
      Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
      Review-Url: https://codereview.chromium.org/2526783002
      Cr-Original-Commit-Position: refs/heads/master@{#41275}
      Cr-Commit-Position: refs/heads/master@{#41411}
      db0c86fa
  24. 30 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Remove raw byte pointers from WasmModule · 6572b562
      clemensh authored
      These byte pointers (module_start and module_end) were only valid
      during decoding. During instantiation or execution, they can get
      invalidated by garbage collection.
      This CL removes them from the WasmModule struct, and introduces a new
      ModuleStorage struct as interface to the wasm wire bytes.
      Since the storage is often needed together with the ModuleEnv, a new
      ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
      The pointers in the ModuleStorage should never escape the live range of
      this struct, as they might point into a SeqOneByteString or ArrayBuffer.
      Therefore, the WasmInterpreter needs to create its own copy of the
      whole module.
      Runtime functions that previously used the raw pointers in WasmModule
      (leading to memory errors) now have to use the SeqOneByteString in the
      WasmCompiledModule.
      
      R=titzer@chromium.org
      BUG=chromium:669518
      
      Review-Url: https://codereview.chromium.org/2540133002
      Cr-Commit-Position: refs/heads/master@{#41388}
      6572b562
  25. 24 Nov, 2016 2 commits
    • clemensh's avatar
      Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5... · 0406620c
      clemensh authored
      Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5 id:80001 of https://codereview.chromium.org/2526783002/ )
      
      Reason for revert:
      Need to revert previous CL because of Android compile error, and this one depends in it.
      
      Original issue's description:
      > [base] Define CHECK comparison for signed vs. unsigned
      >
      > The current CHECK/DCHECK implementation fails statically if a signed
      > value is compared against an unsigned value. The common solution is to
      > cast on each caller, which is tedious and error-prone (might hide bugs).
      > This CL implements signed vs. unsigned comparisons by executing up to
      > two comparisons. For example, if i is int32_t and u is uint_32_t, a
      > DCHECK_LE(i, u) would create the check
      > i <= 0 || static_cast<uint32_t>(i) <= u.
      > For checks against constants, at least one of the checks can be removed
      > by compiler optimizations.
      >
      > The tradeoff we have to make is to sometimes silently execute an
      > additional comparison. And we increase code complexity of course, even
      > though the usage is just as easy (or even easier) as before.
      >
      > The compile time impact seems to be minimal:
      > I ran 3 full compilations for Optdebug on my local machine, one time on
      > the current ToT, one time with this CL plus http://crrev.com/2524093002.
      > Before: 143.72 +- 1.21 seconds
      > Now: 144.18 +- 0.67 seconds
      >
      > In order to check that the new comparisons are working, I refactored
      > some DCHECKs in wasm to use the new magic.
      >
      > R=bmeurer@chromium.org, titzer@chromium.org
      >
      > Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
      > Cr-Commit-Position: refs/heads/master@{#41275}
      
      TBR=ishell@chromium.org,titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review-Url: https://codereview.chromium.org/2531533003
      Cr-Commit-Position: refs/heads/master@{#41277}
      0406620c
    • clemensh's avatar
      [base] Define CHECK comparison for signed vs. unsigned · 5925074a
      clemensh authored
      The current CHECK/DCHECK implementation fails statically if a signed
      value is compared against an unsigned value. The common solution is to
      cast on each caller, which is tedious and error-prone (might hide bugs).
      This CL implements signed vs. unsigned comparisons by executing up to
      two comparisons. For example, if i is int32_t and u is uint_32_t, a
      DCHECK_LE(i, u) would create the check
      i <= 0 || static_cast<uint32_t>(i) <= u.
      For checks against constants, at least one of the checks can be removed
      by compiler optimizations.
      
      The tradeoff we have to make is to sometimes silently execute an
      additional comparison. And we increase code complexity of course, even
      though the usage is just as easy (or even easier) as before.
      
      The compile time impact seems to be minimal:
      I ran 3 full compilations for Optdebug on my local machine, one time on
      the current ToT, one time with this CL plus http://crrev.com/2524093002.
      Before: 143.72 +- 1.21 seconds
      Now: 144.18 +- 0.67 seconds
      
      In order to check that the new comparisons are working, I refactored
      some DCHECKs in wasm to use the new magic.
      
      R=bmeurer@chromium.org, titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2526783002
      Cr-Commit-Position: refs/heads/master@{#41275}
      5925074a
  26. 21 Nov, 2016 1 commit
  27. 16 Nov, 2016 1 commit
  28. 11 Nov, 2016 1 commit
  29. 10 Nov, 2016 1 commit