1. 12 Jul, 2017 1 commit
  2. 05 Jul, 2017 1 commit
  3. 12 Jun, 2017 1 commit
  4. 08 Jun, 2017 1 commit
    • bbudge's avatar
      [WASM] Eliminate SIMD boolean vector types. · 381f7da0
      bbudge authored
      - Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
      - All vector comparisons return v128 type.
      - Eliminates b1xN and, or, xor, not.
      - Selects take a v128 mask vector and are now bit-wise.
      - Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
      
      LOG=N
      BUG=v8:6020
      
      Review-Url: https://codereview.chromium.org/2919203002
      Cr-Commit-Position: refs/heads/master@{#45795}
      381f7da0
  5. 16 May, 2017 1 commit
  6. 09 May, 2017 2 commits
  7. 12 Apr, 2017 1 commit
    • binji's avatar
      [SAB] Validate index before value conversion using ToIndex · 7b300ba2
      binji authored
      It's required by the spec -- and observable -- that the index be validated
      before the conversion of the value(s) via ToInteger.
      
      The previous implementation also had an old test for validating the atomic
      index, which has now been switched to ToIndex.
      
      This also exposed an issue in the ia32 code generator: cmpxchg_b requires a
      byte register, but the ia32 instruction selector was ensuring that the
      new_value was a byte register, not the TempRegister. This change forces the
      temp register to use edx, which always can be used as a byte register (dl).
      This is the same behavior as currently used in UseByteRegister.
      
      BUG=v8:4614
      R=jarin@chromium.org,jkummerow@chromium.org
      
      Review-Url: https://codereview.chromium.org/2814753003
      Cr-Commit-Position: refs/heads/master@{#44626}
      7b300ba2
  8. 11 Apr, 2017 1 commit
  9. 31 Mar, 2017 1 commit
  10. 29 Mar, 2017 1 commit
  11. 16 Mar, 2017 1 commit
  12. 13 Mar, 2017 1 commit
  13. 10 Mar, 2017 1 commit
  14. 07 Mar, 2017 1 commit
  15. 28 Feb, 2017 2 commits
  16. 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
  17. 14 Feb, 2017 1 commit
  18. 12 Feb, 2017 1 commit
  19. 10 Feb, 2017 1 commit
  20. 09 Feb, 2017 2 commits
  21. 01 Feb, 2017 3 commits
  22. 13 Jan, 2017 1 commit
  23. 05 Jan, 2017 1 commit
  24. 28 Dec, 2016 1 commit
  25. 19 Dec, 2016 1 commit
  26. 15 Dec, 2016 2 commits
    • ahaas's avatar
      [wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32. · f435d622
      ahaas authored
      Original commit message:
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
      
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2571813002
      Cr-Commit-Position: refs/heads/master@{#41735}
      f435d622
    • ahaas's avatar
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. · 7bd61b60
      ahaas authored
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2562393002
      Cr-Commit-Position: refs/heads/master@{#41720}
      7bd61b60
  27. 14 Dec, 2016 1 commit
  28. 13 Dec, 2016 1 commit
  29. 30 Nov, 2016 2 commits
  30. 03 Nov, 2016 1 commit
  31. 19 Oct, 2016 1 commit
  32. 09 Sep, 2016 1 commit
  33. 29 Aug, 2016 1 commit
    • mvstanton's avatar
      [Turbofan]: Use new MachineTypes in access-builder. · 56429fc1
      mvstanton authored
      Introduced MachineType::TaggedSigned() and TaggedPointer().
      
      The idea is to quit using the representational dimension of Type, and
      instead encode this information in the MachineRepresentation (itself
      lightly wrapped in MachineType, along with MachineSemantic).
      
      There are three parts to the whole change:
      
      1) Places that set the machine representation - constant nodes, loads nad
         stores, global object and native context specialization.
      
      2) Places that propagate type/representation - this is representation
         inference (aka simplified lowering). At the end of this process we
         expect to have a MachineRepresentation for every node. An interesting
         part of this is phi merging.
      
      3) Places that examine representation - WriteBarrier elimination does this.
         Currently it's looking at the Type representation dimension, but as
         a part of this change (or in a soon-to-follow change) it can simply
         examine the MachineRepresentation.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2258073002
      Cr-Commit-Position: refs/heads/master@{#38978}
      56429fc1