Skip to content

V
V8
Switch branch/tag
  1. 15 Sep, 2022 1 commit
  3. 26 Aug, 2022 1 commit
  5. 22 Aug, 2022 1 commit
  7. 18 Aug, 2022 1 commit
  9. 16 Aug, 2022 2 commits
  11. 12 Aug, 2022 1 commit
  13. 11 Aug, 2022 1 commit
    • Darius M's avatar
      [compiler] Remove delayed string constants · de04959f
      Darius M authored 
      StringConstantXXX were introduced when we switched to concurrent
compilation, as a way to build strings in Turbofan in a background
thread, without having to actually allocate them on the main heap
from the background. See https://crrev.com/c/1221807.

Now that we have local heaps, we can actually allocate strings from
the background, making StringConstantXXX useless.

Moreover, we would fold constant string concatenations into
ConsString, which sounds a bit dubious for performance. Now, small
constant string concatenations will be folded into SeqStrings, while
larger ones will remain ConsString, just to avoid the quadratic
worst-case.

Change-Id: I0479d16aa5691c9d774187c4cc0d03ff4fe2b4f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811291Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82381}
      de04959f
  15. 09 Aug, 2022 1 commit
    • Qifan Pan's avatar
      Reland "Reland "[TurboFan] Support BigIntMultiply"" · 25530fd6
      Qifan Pan authored 
      This is a reland of commit 30ee0690

Avoid terminating from another thread in unit tests to make the termination of optimized bigint multiplication deterministic on windows

Original change's description:
> Reland "[TurboFan] Support BigIntMultiply"
>
> This is a reland of commit ccde4205
>
> Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
>
> Original change's description:
> > [TurboFan] Support BigIntMultiply
> >
> > Bug: v8:9407
> > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#82140}
>
> Bug: v8:9407
> Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82232}

Bug: v8:9407
Change-Id: I7d04897f4e8f260aba31dbad55ce1263406473d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819621
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82304}
      25530fd6
  17. 05 Aug, 2022 2 commits
    • Francis McCabe's avatar
      Revert "Reland "[TurboFan] Support BigIntMultiply"" · 8b63cc9b
      Francis McCabe authored 
      This reverts commit 30ee0690.

Reason for revert: breaks something on windows: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64/47755/overview

Original change's description:
> Reland "[TurboFan] Support BigIntMultiply"
>
> This is a reland of commit ccde4205
>
> Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
>
> Original change's description:
> > [TurboFan] Support BigIntMultiply
> >
> > Bug: v8:9407
> > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#82140}
>
> Bug: v8:9407
> Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82232}

Bug: v8:9407
Change-Id: I006ed3770564149ae146c614c3d693de9ec29e41
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812289
Owners-Override: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
Auto-Submit: Francis McCabe <fgm@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82233}
      8b63cc9b
    • Qifan Pan's avatar
      Reland "[TurboFan] Support BigIntMultiply" · 30ee0690
      Qifan Pan authored 
      This is a reland of commit ccde4205

Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location

Original change's description:
> [TurboFan] Support BigIntMultiply
>
> Bug: v8:9407
> Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82140}

Bug: v8:9407
Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82232}
      30ee0690
  19. 03 Aug, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "[TurboFan] Support BigIntMultiply" · 8851a274
      Nico Hartmann authored 
      This reverts commit ccde4205.

Reason for revert: Investigating performance regressions

Original change's description:
> [TurboFan] Support BigIntMultiply
>
> Bug: v8:9407
> Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82140}

Bug: v8:9407
Change-Id: I21de9fd43df2e043b4019d2bad560329ef0971b4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807584
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82168}
      8851a274
  21. 02 Aug, 2022 1 commit
  23. 13 Jul, 2022 1 commit
  25. 08 Jul, 2022 1 commit
  27. 05 Jul, 2022 2 commits
    • Maya Lekova's avatar
      Reland "[fastcall] Support EnforceRange annotation" · 8559a04f
      Maya Lekova authored 
      This is a reland of commit 84e078c6. It fixes an undefined behaviour and guards against NaNs in d8-test.cc.

Original change's description:
> [fastcall] Support EnforceRange annotation
>
> This CL implements checks in case EnforceRange is requested for a
> given parameter by using TryTruncate* operators. It implements 2 such
> truncations on x64 and arm64 - TryTruncateFloat64ToInt32 and
> TryTruncateFloat64ToUint32.
>
> Bug: chromium:1052746
> Change-Id: I32f34d9dc1265af568cc576663620a8f7f8245f6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721618
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81512}

Bug: chromium:1052746, chromium:1341851, chromium:1341891
Change-Id: I21e0e452c92cc93f8b06985a335f409855be0546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3743518Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81529}
      8559a04f
    • Manos Koukoutos's avatar
      Revert "[fastcall] Support EnforceRange annotation" · d9b62c16
      Manos Koukoutos authored 
      This reverts commit 84e078c6.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/22000/overview

Original change's description:
> [fastcall] Support EnforceRange annotation
>
> This CL implements checks in case EnforceRange is requested for a
> given parameter by using TryTruncate* operators. It implements 2 such
> truncations on x64 and arm64 - TryTruncateFloat64ToInt32 and
> TryTruncateFloat64ToUint32.
>
> Bug: chromium:1052746
> Change-Id: I32f34d9dc1265af568cc576663620a8f7f8245f6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721618
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81512}

Bug: chromium:1052746
Change-Id: I2218681c7cb5d05dea6d8ac5347b19bc0070c1a6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3743514
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81513}
      d9b62c16
  29. 04 Jul, 2022 1 commit
  31. 23 Jun, 2022 1 commit
  33. 07 Jun, 2022 1 commit
  35. 03 Jun, 2022 1 commit
  37. 31 May, 2022 1 commit
  39. 30 May, 2022 1 commit
  41. 25 May, 2022 1 commit
  43. 10 May, 2022 1 commit
  45. 31 Mar, 2022 1 commit
  47. 29 Mar, 2022 1 commit
  49. 23 Mar, 2022 1 commit
    • Nico Hartmann's avatar
      Reland "[turbofan] Enable --verify-simplified-lowering in debug" · 87d73a3a
      Nico Hartmann authored 
      This reverts commit aaedd8b7.

Changes in the reland:
The inital problem was caused by nodes that were removed during SL
because they are no-ops but have an effect on typing (in the repro, this
was e.g. PlainPrimitiveToNumber). The reland introdocues a new operator
SLVerifierHint that is used exclusively in SL to provide hints to the
verifier and that solves this problem. SLVerifierHint also replaces the
previous use of TypeGuard to type constant nodes for the verifier.

Bug: v8:12619, chromium:1302572
Change-Id: I0957645c03d8b7c26cd6d630a1ecbd0a6a8223ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3512574Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79564}
      87d73a3a
  51. 21 Mar, 2022 1 commit
  53. 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
  55. 24 Feb, 2022 1 commit
  57. 16 Feb, 2022 1 commit
  59. 14 Feb, 2022 1 commit
    • Leszek Swirski's avatar
      [utils] Move BitVector's iterator to STL-like interface. · 59ea4881
      Leszek Swirski authored 
      Replace the Advance/Done methods on BitVector::Iterator with
STL-compatible operator overloads, and add begin/end methods to
BitVector itself, so that BitVectors can be iterated with ranged for
loops.

As a drive-by cleanup, make GrowableBitVector hold the BitVector by
value (to avoid needing to allocate one for empty iteration), and remove
its unused (and inefficient) Union method.

Change-Id: Idcd34e26bfb087e3ec8297b4a769a51bfab4b6e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455803Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79071}
      59ea4881
  61. 13 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored 
      This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).

Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:

1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.

This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).

Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  63. 09 Dec, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm][turbofan] Immutable object operators · 4113cf64
      Manos Koukoutos authored 
      Design doc: bit.ly/36MfD6Y

We introduce simplified operators LoadImmutableFromObject and
InitializeImmutableInObject. These are lowered to Loads and Stores like
LoadFromObject and StoreToObject.
We split CsaLoadElimination::AbstractState in two HalfStates,
which represent the mutable and immutable component of the state.
Immutable operators in the effect chain modify the immutable half-state,
and plain operators modify the mutable half-state. The immutable part is
maintained through write effects and loop headers. Immutable
initializations do not lookup and kill previous overlapping stores,
assuming each offset cannot be initialized more than once.

Bug: v8:11510

Change-Id: I0f5feca3354fdd3bdc1f511cc5214ec51e1407ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268728Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78325}
      4113cf64
  65. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored 
      This is a reland of 45227ffd
Differences:
- Handle one more flags conflict in variants.py.
- Disallow %VerifyType without --concurrent-recompilation.

Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
>    OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
>    HeapConstant Factory::zero_string(). However, NumberToString does
>    not always produce this string. To avoid regressions, the CL keeps
>    the HeapConstant type and changes the runtime and builtin code to
>    always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}

Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  67. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored 
      This reverts commit 45227ffd.

Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview

Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
>    OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
>    HeapConstant Factory::zero_string(). However, NumberToString does
>    not always produce this string. To avoid regressions, the CL keeps
>    the HeapConstant type and changes the runtime and builtin code to
>    always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}

Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77566}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored 
      Extend type assertions to all types covering JavaScript values.
This is achieved by allocating type representations on the heap using
newly defined HeapObject subclasses. To allocate these in the compiler,
we disable concurrent compilation for the --assert-types flag for now.

Fix two type errors that came up with the existing tests:
1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
   OtherObject.
2. OperationTyper::NumberToString(Type) can type the result as the
   HeapConstant Factory::zero_string(). However, NumberToString does
   not always produce this string. To avoid regressions, the CL keeps
   the HeapConstant type and changes the runtime and builtin code to
   always produce the canonical "0" string.

A few tests were failing because they check for truncations to work
and prevent deoptimization. However, AssertType nodes destroy all
truncations (which is by design), so these tests are incompatible
and now disabled for the assert_types variant.

Drive-by fix: a few minor Torque issues that came up.

Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  69. 19 Oct, 2021 1 commit
  71. 13 Oct, 2021 1 commit
    • Joyee Cheung's avatar
      [class] Add IC support for defining class fields to replace runtime call · 713ebae3
      Joyee Cheung authored 
      Introduces several new runtime mechanics for defining private fields,
including:
  - Bytecode StaKeyedPropertyAsDefine
  - Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
  - Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
  - TurboFan IR opcode JSDefineProperty

These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).

The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.

Details:

New bytecodes:
  - StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
    but with a different IC builtin (KeyedDefineOwnIC). This is a
    bytecode rather than a flag for the existing StaKeyedProperty in
    order to avoid impacting typical keyed stores in any way due to
    additional branching and testing.

New builtins:
  - StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
    StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
    no longer look up the property name in the prototype.
    In adddition, this CL changes an assumption that
    StoreNamedOwnProperty can't result in a map transition, as we
    can't rely on the property already being present in the Map due
    to an object literal boilerplate.

    In the context of class features, this replaces the runtime
    function %CreateDataProperty().

  - KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
    new StaKeyedPropertyAsDefine bytecode. This is similar to an
    ordinary KeyedStoreIC, but will not check the prototype for
    setters, and for private fields, will take the slow path if the
    field already exists.

    In the context of class features, this replaces the runtime
    function %AddPrivateField().

TurboFan IR:
  - JSDefineProperty is introduced to represent a situation where we
    need to use "Define" semantics, in particular, it codifies that we
    do not consult the prototype chain, and the semantics relating to
    private fields are implied as well.

R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org

Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
      713ebae3