Skip to content

V
V8
Switch branch/tag
  1. 19 Apr, 2022 1 commit
    • Jakob Linke's avatar
      Revert "[interpreter] Optimize strict equal boolean" · 3b772a23
      Jakob Linke authored 
      This reverts commit 62632c08.

Reason for revert: Performance regressions crbug.com/1315724

Original change's description:
> [interpreter] Optimize strict equal boolean
>
> For strict equal boolean literal like "a===true"
> or "a===false", we could generate TestReferenceEqual
> rather than TestStrictEqual. And in `execution_result()->IsTest()`
> case, we could directly emit JumpIfTrue/JumpIfFalse.
>
> E.g.
> ```
> a === true
> ```
> Generated Bytecode From:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestEqualStrict
> ```
> To:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestReferenceEqual
> ```
>
> E.g.
> ```
> if (a === true)
> ```
> Generated Bytecode From:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestEqualStrict
> JumpIfFalse
> ```
> To
> ```
> LdaGlobal
> JumpIfTrue
> Jump
> ```
>
>
> Bug: v8:6403
> Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Cr-Commit-Position: refs/heads/main@{#79935}

Bug: v8:6403, chromium:1315724
Change-Id: I65c520590093724e838f738c795d229687efb9de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592752Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80010}
      3b772a23
  3. 12 Apr, 2022 1 commit
    • jameslahm's avatar
      [interpreter] Optimize strict equal boolean · 62632c08
      jameslahm authored 
      For strict equal boolean literal like "a===true"
or "a===false", we could generate TestReferenceEqual
rather than TestStrictEqual. And in `execution_result()->IsTest()`
case, we could directly emit JumpIfTrue/JumpIfFalse.

E.g.
```
a === true
```
Generated Bytecode From:
```
LdaGlobal
Star1
LdaTrue
TestEqualStrict
```
To:
```
LdaGlobal
Star1
LdaTrue
TestReferenceEqual
```

E.g.
```
if (a === true)
```
Generated Bytecode From:
```
LdaGlobal
Star1
LdaTrue
TestEqualStrict
JumpIfFalse
```
To
```
LdaGlobal
JumpIfTrue
Jump
```


Bug: v8:6403
Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#79935}
      62632c08
  5. 21 Mar, 2022 1 commit
  7. 17 Mar, 2022 1 commit
  9. 14 Mar, 2022 1 commit
  11. 08 Mar, 2022 1 commit
    • Joyee Cheung's avatar
      [ic] name Set/Define/Store property operations more consistently · 0d1ffe30
      Joyee Cheung authored 
      For background and reasoning, see
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
This is the first step towards pulling the DefineNamedOwn operation out
of StoreIC.

Summary of the renamed identifiers:

Bytecodes:

- StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
  normal named property sets like obj.x = 1.
- StaNamedOwnProperty -> DefineNamedOwnProperty: calls
  DefineNamedOwnIC (previously StoreOwnIC), and emitted for
  initialization of named properties in object literals and named
  public class fields.
- StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
  for keyed property sets like obj[x] = 1.
- StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
  DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
  initialization of private class fields and computed public class
  fields.
- StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
  DefineKeyedOwnPropertyInLiteral runtime function (previously
  DefineDataPropertyInLiteral) and emitted for initialization of keyed
  properties in object literals and static class initializers. (note
  that previously the StoreDataPropertyInLiteral runtime function name
  was taken by object spreads and array literal creation instead)
- LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
  GetNamedProperty, LdaNamedPropertyFromSuper ->
  GetNamedPropertyFromSuper: we drop the Sta prefix for the property
  store operations since the accumulator use is implicit and to make
  the wording more natural, for symmetry the Lda prefix for the
  property load operations is also dropped.

opcodes:

- (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
  named properties, compiled from SetNamedProperty (previously
  StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
- (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
  semantics for initializing named own properties in object literal and
  public class fields, compiled from DefineNamedOwnProperty (previously
  StaNamedOwnProperty) and lowers to DefineNamedOwnIC
  (previously StoreOwnIC)
- (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
  for keyed properties, only compiled from SetKeyedProperty(previously
  StaKeyedProperty) and lowers to KeyedStoreIC
- (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
  semantics for initialization of private class fields and computed
  public class fields, compiled from DefineKeyedOwnProperty (previously
  StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
  KeyedDefineOwnIC).
- (JS)StoreDataPropertyInLiteral ->
  (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
  initialization of keyed properties in object literals and static
  class initializers, compiled from DefineKeyedOwnPropertyInLiteral
  (previously StaDataPropertyInLiteral) and calls the
  DefineKeyedOwnPropertyInLiteral runtime function (previously
  DefineDataPropertyInLiteral).

Runtime:
- DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
  following the bytecode/opcodes change, this is used by
  DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
  for object and class literal initialization.
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
  it's just a simplified version of DefineDataPropertyInLiteral that
  does not update feedback or perform function name configuration.
  This is used by object spread and array literal creation. Since we
  are renaming DefineDataPropertyInLiteral to
  DefineKeyedOwnPropertyInLiteral, rename this simplified version with
  a `_Simple` suffix. We can consider merging it into
  DefineKeyedOwnPropertyInLiteral in the future. See
  https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
- Other changes following the bytecode/IR changes

IC:

- StoreOwn -> DefineNamedOwn: used for initialization of named
  properties in object literals and named public class fields.
  - StoreOwnIC -> DefineNamedOwnIC
  - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
  - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
  - IsStoreOwn() -> IsDefineNamedOwn()
- DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
  IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
  keyed defines so we don't need an extra generic predicate.
  - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
  - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
  - IsDefineOwn() -> IsDefineKeyedOwn()
  - IsDefineOwnIC() -> IsDefineKeyedOwnIC()
  - Removing IsKeyedDefineOwnIC() as its now a duplicate of
    IsDefineKeyedOwnIC()
- KeyedDefineOwnIC -> DefineKeyedOwnIC,
  KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
  make the ordering of terms more consistent
- IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
  DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
  removed since it's just a duplicate of this.
- IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
  "keyed" part came from, but it's only used when DefineNamedOwnIC
  (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly

Interpreter & compiler:
- BytecodeArrayBuilder: following bytecode changes
    - StoreNamedProperty -> SetNamedProperty
  - StoreNamedOwnProperty -> DefineNamedOwnProperty
  - StoreKeyedProperty -> SetKeyedProperty
  - DefineKeyedProperty -> DefineKeyedOwnProperty
  - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
- FeedbackSlotKind:
  - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
    consistent
  - kStoreOwnNamed -> kDefineNamedOwn: following the IC change
  - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
    used in StoreIC for set semantics
  - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
    in KeyedStoreIC for set semantics
  - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
    following the IC change
- BytecodeGraphBuilder
  - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
    is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
    difference between SetNamedProperty and DefineNamedOwnProperty
    operations.

Not changed:

- StoreIC and KeyedStoreIC currently contain mixed logic for both Set
  and Define operations, and the paths are controlled by feedback. The
  plan is to refactor the hierarchy like this:
  ```
  - StoreIC
    - DefineNamedOwnIC
    - SetNamedIC (there could also be a NamedStoreIC if that's helpful)
    - KeyedStoreIC
      - SetKeyedIC
      - DefineKeyedOwnIC
      - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
      - StoreInArrayLiteralIC
    - ...
  ```
  StoreIC and KeyedStoreIC would then contain helpers shared by their
  subclasses, therefore it still makes sense to keep the word "Store"
  in their names since they would be generic base classes for both set
  and define operations.
- The Lda and Sta prefixes of bytecodes not involving object properties
  (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
  property operations, and distinction between Set and Define might be
  less relevant or nonexistent for bytecodes not involving object
  properties. We could consider rename some of them in future patches
  if that's helpful though.

Bug: v8:12548
Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79409}
      0d1ffe30
  13. 09 Feb, 2022 1 commit
  15. 02 Dec, 2021 1 commit
  17. 25 Nov, 2021 1 commit
  19. 06 Nov, 2021 1 commit
  21. 05 Nov, 2021 1 commit
  23. 02 Nov, 2021 1 commit
    • Joyee Cheung's avatar
      [class] refactor ClassFields benchmarks and copy them into JSTests3 · d28bfcd5
      Joyee Cheung authored 
      This patch refactors the ClassFields benchmarks and makes the results
detection work properly. Previously the errors weren't caught since
the ClassFields benchmarks don't get run in the perf_integration
step in the CI.

- Instead of putting different configs (single/multiple fields, type
  of fields, etc.)in the JSON configuration, we now group the related
  benchmarks into the same script and run the different configurations
  in the scripts directly. Only the optimization status is now
  controlled in JSON. All the class fields definition benchmarks are
  merged into initialize-class.js.
- Update the number of local iterations of evaluate-class.js to 100
  (similar to most of other benchmarks) to keep the time spent on
  this benchmark similar to that of other benchmarks.

In addition, copy the configs to JSTests3 so that the benchmarks gets
run by the perf_integration step and we can see the graphs on
http://chromeperf.appspot.com/report. These can be removed
when the ClassFields benchmark results are generated there too.

Bug: v8:10793, v8:9888
Change-Id: I4e677bdc7b582650f39cf6e9ec02775c57fd04ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226550
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77640}
      d28bfcd5
  25. 12 Oct, 2021 3 commits
  27. 26 Aug, 2021 1 commit
  29. 19 Aug, 2021 1 commit
  31. 12 Aug, 2021 1 commit
  33. 23 Jun, 2021 1 commit
    • Mihir Shah's avatar
      A jump-table implementation for constant case switch statements · 9711289d
      Mihir Shah authored 
      The change is made since for switch statements with lots of cases,
where each case is a constant integer, the emitted bytecode is still
a series of jumps, when we can instead use a jump table.

If there are 6 or more cases (similar to GCC) of Smi literals, and
if the max Smi case minus the min Smi case is not more than 3 times
the number of cases, we use a jump table up front to handle Smi's,
and then use traditional if-else logic for the rest of the cases.

We then use the jump table in interpreter/bytecode-jump-table to
do the optimization.

This tries to go off issue 9738 in v8's issue tracker. It is not
exactly the same, since that recommends doing the work at JIT-time,
but has similar ideas. It also partially goes off issue 10764.

Bug: v8:9738
Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75323}
      9711289d
  35. 01 Jun, 2021 1 commit
  37. 25 Feb, 2021 1 commit
  39. 16 Nov, 2020 1 commit
    • Marja Hölttä's avatar
      [super] Rewrite perf tests · 7ed98981
      Marja Hölttä authored 
      - Add tests comparing super property access to normal property access
- Shift the work so that the framework takes less time and the thing
we're trying to measure takes more time.
- Optimize / disable the optimization for the target function, not the
whole test framework.
- Reduce the amount of boilerplate code in the tests.

Bug: v8:9237
Change-Id: Idde133298c9b8ffb3d49945ef9c67f5039634598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536635Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71196}
      7ed98981
  41. 31 Aug, 2020 1 commit
  43. 25 Aug, 2020 1 commit
  45. 24 Aug, 2020 1 commit
  47. 30 Jul, 2020 1 commit
  49. 01 Jul, 2020 1 commit
  51. 29 Jun, 2020 1 commit
  53. 04 May, 2020 1 commit
  55. 12 Feb, 2020 1 commit
  57. 22 Oct, 2019 1 commit
  59. 09 Oct, 2019 1 commit
  61. 16 Aug, 2019 1 commit
  63. 12 Jul, 2019 2 commits
  65. 04 Jul, 2019 2 commits
  67. 01 Jul, 2019 3 commits