Skip to content

V
V8
Switch branch/tag
  1. 09 Aug, 2018 1 commit
  3. 19 Jul, 2018 1 commit
  5. 03 Jul, 2018 1 commit
  7. 22 Jun, 2018 1 commit
  9. 05 Jun, 2018 1 commit
    • Simon Zünd's avatar
      Reland "[array] Implement Array.p.sort in Torque" · aff80345
      Simon Zünd authored 
      This is a reland of df1676e6

Original change's description:
> [array] Implement Array.p.sort in Torque
>
> This CL implements a generic baseline version and 3 fastpaths, for
> various elements kinds, of Array.p.sort in Torque. Details can be found
> in the Design Doc: https://goo.gl/Ge321G.
>
> Performance impact on micro benchmarks depends on the element kind
> and whether the user provides a comparison function.
> For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across
> the board. For Dictionary we are slower in all micro benchmarks (0.7).
> For PackedSmi it depends on the call site and whether or not a
> comparison function is used.
>
> Detailed numbers: https://goo.gl/mTyPSb
>
> Bug: v8:7382
> Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e
> Reviewed-on: https://chromium-review.googlesource.com/1061523
> Commit-Queue: Simon Zünd <szuend@google.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53481}

Bug: v8:7382,v8:7806,chromium:849293
Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69
Reviewed-on: https://chromium-review.googlesource.com/1086827Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#53511}
      aff80345
  11. 04 Jun, 2018 2 commits
    • Jakob Gruber's avatar
      Revert "[array] Implement Array.p.sort in Torque" · 3348ed0b
      Jakob Gruber authored 
      This reverts commit df1676e6.

Reason for revert: https://crbug.com/v8/7382#c26

Original change's description:
> [array] Implement Array.p.sort in Torque
> 
> This CL implements a generic baseline version and 3 fastpaths, for
> various elements kinds, of Array.p.sort in Torque. Details can be found
> in the Design Doc: https://goo.gl/Ge321G.
> 
> Performance impact on micro benchmarks depends on the element kind
> and whether the user provides a comparison function.
> For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across
> the board. For Dictionary we are slower in all micro benchmarks (0.7).
> For PackedSmi it depends on the call site and whether or not a
> comparison function is used.
> 
> Detailed numbers: https://goo.gl/mTyPSb
> 
> Bug: v8:7382
> Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e
> Reviewed-on: https://chromium-review.googlesource.com/1061523
> Commit-Queue: Simon Zünd <szuend@google.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53481}

TBR=cbruni@chromium.org,jgruber@chromium.org,szuend@google.com

Change-Id: I4c1b32a434d49caba67c80bccb068390607f90a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7382
Reviewed-on: https://chromium-review.googlesource.com/1085407Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53494}
      3348ed0b
    • Simon Zünd's avatar
      [array] Implement Array.p.sort in Torque · df1676e6
      Simon Zünd authored 
      This CL implements a generic baseline version and 3 fastpaths, for
various elements kinds, of Array.p.sort in Torque. Details can be found
in the Design Doc: https://goo.gl/Ge321G.

Performance impact on micro benchmarks depends on the element kind
and whether the user provides a comparison function.
For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across
the board. For Dictionary we are slower in all micro benchmarks (0.7).
For PackedSmi it depends on the call site and whether or not a
comparison function is used.

Detailed numbers: https://goo.gl/mTyPSb

Bug: v8:7382
Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e
Reviewed-on: https://chromium-review.googlesource.com/1061523
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53481}
      df1676e6
  13. 14 May, 2018 1 commit
  15. 07 May, 2018 1 commit
  17. 04 May, 2018 1 commit
  19. 30 Apr, 2018 1 commit
  21. 27 Apr, 2018 1 commit
  23. 10 Apr, 2018 1 commit
  25. 28 Mar, 2018 3 commits
  27. 26 Mar, 2018 1 commit
  29. 22 Mar, 2018 2 commits
  31. 19 Mar, 2018 2 commits
  33. 16 Mar, 2018 1 commit
  35. 15 Mar, 2018 1 commit
  37. 14 Mar, 2018 1 commit
  39. 08 Mar, 2018 1 commit
  41. 26 Feb, 2018 1 commit
  43. 21 Feb, 2018 1 commit
  45. 01 Feb, 2018 2 commits
  47. 31 Jan, 2018 2 commits
  49. 30 Jan, 2018 3 commits
  51. 26 Jan, 2018 1 commit
  53. 23 Jan, 2018 1 commit
  55. 17 Jan, 2018 2 commits
    • Clemens Hammacher's avatar
      [wasm] Distinguish Liftoff code from Turbofan code · 41f231a2
      Clemens Hammacher authored 
      For memory tracing, output a 'T' for Turbofan code and an 'L' for
Liftoff code. To do this, the WasmCodeWrapper now has some dispatch
functions which work for both on-the-heap and off-the-heap code.
We can probably refactor more code by having this mechanism.

Since the output of --wasm-trace-memory differs now between Turbofan
and Liftoff, the message test is split in two.

R=titzer@chromium.org
CC=mstarzinger@chromium.org

Bug: v8:6600
Change-Id: Ic5fd18c631f5c8aaad19d639df75b18098895b5a
Reviewed-on: https://chromium-review.googlesource.com/868214Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50655}
      41f231a2
    • Clemens Hammacher's avatar
      [Liftoff] Add memory tracing support · 4dc85663
      Clemens Hammacher authored 
      This adds support for tracing memory operations in code compiled with
Liftoff. This is the first runtime call we emit from Liftoff code, so
part of this code can be reused for other runtime calls.

Drive-by: Reuse outer compilation zone (avoid one Zone allocation).

Bug: v8:6600, v8:7210
Change-Id: I8b22088d0685338d533d328cb371384210e0ed22
Reviewed-on: https://chromium-review.googlesource.com/864663Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50652}
      4dc85663
  57. 15 Jan, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Refactor memory tracing · 183204f8
      Clemens Hammacher authored 
      Instead of passing four arguments to the runtime function, just pass
one pointer to a struct containing all information. This makes it much
easier to implement memory tracing in Liftoff in a follow-up CL.
Also fix a few other minor things like the namespace and the include
guards.

R=titzer@chromium.org

Change-Id: I47d8827cbb896a581585947f594af52f42bdb37c
Reviewed-on: https://chromium-review.googlesource.com/863673Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50568}
      183204f8
  59. 12 Jan, 2018 1 commit