Skip to content

V
V8
Switch branch/tag
  1. 05 Aug, 2019 1 commit
    • Mythri A's avatar
      Reland "[ic] Don't transition to premonomorphic state" · 2999cea5
      Mythri A authored 
      This is a reland of 159df248

Original change's description:
> [ic] Don't transition to premonomorphic state
> 
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
> 
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
> 
> 
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}

Change-Id: Ica7eb65649615c2f8410d5b815a98b55cb1cfc4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731000
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63082}
      2999cea5
  3. 01 Aug, 2019 2 commits
  5. 12 Jul, 2019 1 commit
  7. 05 Jul, 2019 1 commit
  9. 19 Jun, 2019 1 commit
  11. 13 Jun, 2019 1 commit
  13. 23 May, 2019 1 commit
  15. 22 May, 2019 1 commit
  17. 21 May, 2019 1 commit
  19. 15 May, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland: [csa] verify skipped write-barriers in MemoryOptimizer · a19c3ffb
      Tobias Tebbi authored 
      With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.

Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).

Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
  Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.

Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
  (for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
  We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
  but in CSA.

Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).

Reland Change: Support pointer compression operands.

R=jarin@chromium.org
TBR=mvstanton@chromium.org

Bug: v8:7793
Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61522}
      a19c3ffb
  21. 29 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [runtime] Optimize general object spread. · 4995c85f
      Benedikt Meurer authored 
      This adds a new %_CopyDataProperties intrinsic, that reuses most of the
existing machinery that we already have in place for Object.assign() and
computed property names in object literals. This speeds up the general
case for object spread (where the spread is not the first item in an
object literal) and brings it on par with Object.assign() at least - in
most cases it's significantly faster than Object.assign().

In the test case [1] referenced from the bug, the performance goes from

  objectSpreadLast: 3624 ms.
  objectAssignLast: 1938 ms.

to

  objectSpreadLast: 646 ms.
  objectAssignLast: 1944 ms.

which corresponds to a **5-6x performance boost**, making object spread
faster than Object.assign() in general.

Drive-by-fix: This refactors the Object.assign() fast-path in a way that
it can be reused appropriately for object spread, and adds another new
builtin SetDataProperties, which does the core of the Object.assign()
work. We can teach TurboFan to inline Object.assign() based on the new
SetDataProperties builtin at some later point to further optimize
Object.assign().

[1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0

Bug: v8:9167
Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61100}
      4995c85f
  23. 26 Apr, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[csa] verify skipped write-barriers in MemoryOptimizer" · dd6c9536
      Ross McIlroy authored 
      This reverts commit da7322c0.

Reason for revert: Breaking the pointer compression bots, e.g.:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047

Original change's description:
> [csa] verify skipped write-barriers in MemoryOptimizer
> 
> With very few exceptions, this verifies all skipped write-barriers in
> CSA and Torque, showing that the MemoryOptimizer together with some
> type information on the stored value are enough to avoid unsafe skipped
> write-barriers.
> 
> Changes to CSA:
> SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
> MemoryOptimizer by default.
> Type information about the stored values (TNode<Smi>) is exploited to
> safely skip write barriers for stored Smi values.
> In some cases, the code is re-structured to make it easier to consume
> for the MemoryOptimizer (manual branch and load elimination).
> 
> Changes to the MemoryOptimizer:
> Improve the MemoryOptimizer to remove write barriers:
> - When the store happens to a CSA-generated InnerAllocate, by ignoring
>   Bitcasts and additions.
> - When the stored value is the HeapConstant of an immortal immovable root.
> - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
> - Fast C-calls are treated as non-allocating.
> - Runtime calls can be white-listed as non-allocating.
> 
> Remaining missing cases:
> - C++-style iterator loops with inner pointers.
> - Inner allocates that are reloaded from a field where they were just stored
>   (for example an elements backing store). Load elimination would fix that.
> - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
>   We could handle that in Torque.
> - Double-aligned allocations, which are not lowered in the MemoryOptimizer
>   but in CSA.
> 
> Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
> can be handled by overload resolution (in Torque and C++).
> 
> R=​jarin@chromium.org
> TBR=mvstanton@chromium.org
> 
> Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61016}

TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org

Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61038}
      dd6c9536
  25. 25 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa] verify skipped write-barriers in MemoryOptimizer · da7322c0
      Tobias Tebbi authored 
      With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.

Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).

Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
  Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.

Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
  (for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
  We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
  but in CSA.

Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).

R=jarin@chromium.org
TBR=mvstanton@chromium.org

Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61016}
      da7322c0
  27. 17 Apr, 2019 1 commit
  29. 29 Mar, 2019 1 commit
  31. 14 Feb, 2019 1 commit
  33. 13 Feb, 2019 2 commits
  35. 28 Jan, 2019 2 commits
  37. 25 Jan, 2019 1 commit
  39. 18 Jan, 2019 1 commit
  41. 22 Nov, 2018 1 commit
  43. 24 Oct, 2018 1 commit
    • Caitlin Potter's avatar
      [builtins] put SetPropertyInLiteral in a code-stub · ac3f98d5
      Caitlin Potter authored 
      There are several core changes in this stub:

1) add a version of KeyedStoreGenericGenerator::SetPropertyInLiteral()
which supports indexed properties directly, witthout KeyedStore

2) add a code stub for SetPropertyInLiteral which uses the version
supporting indexed properties

3) Use the code stub in CloneObjectIC, rather than using the smaller
special-cased version which does not handle Names.

Item 1) involves a refactoring which adds a nice way to reuse code in
KeyedStoreGenericAssembler, which allows deleting a bunch of copy/pasted
code. This makes it easy to reuse the index handling in
KeyedStoreGeneric() without adding adding a bunch more duplicated
handling. Because of this, I consider this to be somewhat of a cleanup,
though if the copied code is preferred, I'm happy to revert to that.

Item 2) is needed for Object.fromEntries(), as it's better to not
require falling back to the slow path if a key happens to be an Smi ---
but this is also optional.

Item 3) benefits the codebase by allowing Object.fromEntries() to use
this fast path without calling into the runtime, and without duplicating
code which is also used by CloneObjectIC.

I am skeptical that this should affect performance significantly. I've
run ObjectLiteralSpread tests, and the mean of scores over 100 runs is
somewhat surprising: CloneObjectIC --- the only user of this code,
has an increased average score, while the polyfill cases score slightly
worse --- However, the overall changes are small and likely flukes.
The complete processed test output is below:

```
// Mean of 100 runs of each benchmark

Babel-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
     | With patch                | Without patch             | diff
Mean | 11530.87                  | 12142.92                  | -5.04%
-----+---------------------------+---------------------------+-------

BabelAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
     | With patch                | Without patch             | diff
Mean | 10881.41                  | 11260.81                  | -3.37%
-----+---------------------------+---------------------------+-------

ObjectAssign-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
     | With patch                | Without patch             | diff
Mean | 6188.92                   | 6358.55                   | -2.67%
-----+---------------------------+---------------------------+-------

ObjectAssignAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
     | With patch                | Without patch             | diff
Mean | 6112.80                   | 6275.54                   | -1.61%
-----+---------------------------+---------------------------+-------

ObjectSpread-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
     | With patch                | Without patch             | diff
Mean | 51942.93                  | 50713.17                  | +3.46%
-----+---------------------------+---------------------------+-------

ObjectSpreadAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
     | With patch                | Without patch             | diff
Mean | 51375.23                  | 50833.29                  | +2.09%
-----+---------------------------+---------------------------+-------
```

BUG=v8:8238, v8:8021
R=ishell@chromium.org, jkummerow@chromium.org

Change-Id: I43e102fc461ffd389b5d6810a73f86e5012d7dee
Reviewed-on: https://chromium-review.googlesource.com/c/1277751
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56957}
      ac3f98d5
  45. 08 Oct, 2018 1 commit
  47. 20 Sep, 2018 1 commit
  49. 11 Sep, 2018 2 commits
  51. 09 Aug, 2018 1 commit
  53. 04 Jun, 2018 1 commit
  55. 01 Jun, 2018 2 commits
  57. 11 May, 2018 1 commit
  59. 09 May, 2018 1 commit
  61. 08 May, 2018 1 commit
  63. 24 Apr, 2018 1 commit
  65. 23 Apr, 2018 2 commits
  67. 18 Apr, 2018 1 commit