Skip to content

V
V8
Switch branch/tag
  1. 13 Jul, 2022 1 commit
  3. 08 Jul, 2022 1 commit
  5. 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
  7. 04 Jul, 2022 1 commit
  9. 23 Jun, 2022 1 commit
  11. 07 Jun, 2022 1 commit
  13. 03 Jun, 2022 1 commit
  15. 31 May, 2022 1 commit
  17. 30 May, 2022 1 commit
  19. 25 May, 2022 1 commit
  21. 10 May, 2022 1 commit
  23. 31 Mar, 2022 1 commit
  25. 29 Mar, 2022 1 commit
  27. 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
  29. 21 Mar, 2022 1 commit
  31. 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
  33. 24 Feb, 2022 1 commit
  35. 16 Feb, 2022 1 commit
  37. 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
  39. 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
  41. 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
  43. 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
  45. 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
  47. 19 Oct, 2021 1 commit
  49. 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
  51. 30 Sep, 2021 1 commit
  53. 12 Aug, 2021 1 commit
  55. 15 Jul, 2021 1 commit
  57. 09 Jul, 2021 1 commit
  59. 06 Jul, 2021 1 commit
    • Z Nguyen-Huu's avatar
      Use type feedback to improve exponentiation. · ae95f46d
      Z Nguyen-Huu authored 
      With this change, we use Float64Pow for both Smi and Float inputs, also
introduce new speculative operator.

For this PoC
==========================================================
let result = [NaN]; // Avoid HeapNumber-boxing the results.

function slow(){
  for(let i = 0; i < 100000000; i++) {
    result[0] = i ** 2;
  }
}

start = Date.now();
slow();
console.log(Date.now() - start);
==========================================================
Before: 1313
After: 112

Bug: v8:11731
Change-Id: I07a1bde068bef8184b9f556be9d1fe2d6a288705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960064
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75590}
      ae95f46d
  61. 01 Jul, 2021 1 commit
  63. 27 May, 2021 1 commit
  65. 25 May, 2021 1 commit
  67. 12 May, 2021 1 commit
    • Manos Koukoutos's avatar
      [turbofan] Disallow floating control in wasm · 02ac71e2
      Manos Koukoutos authored 
      Loop unrolling did not work properly with floating control. Seeing as
very few spots in the wasm compiler introduced floating control, we
decided to disallow it altogether.
Changes:
- When lowering 64-bit rol/ror/clz/ctz in 32-bit platforms, we use a
  diamond operator, which used to introduce floating control. This CL
  adds a control edge to these operators so that the diamond can be
  chained to that control instead.
- During loop analysis, as an additional safety check, we check that the
  explored loop does not have floating control. Exceptionally, floating
  control pointing directly do start() is allowed.
- Change wasm-compiler so that generated floating projections point to
  start() even after stack check patch-in.

Bug: chromium:1184929, v8:11298
Change-Id: I1ee063f5250037ae6c84d2f16b0bd8fff3923117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876851Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74527}
      02ac71e2
  69. 05 May, 2021 1 commit
    • Nico Hartmann's avatar
      [TurboFan] Add %VerifyType intrinsic · f486a343
      Nico Hartmann authored 
      This CL adds a new %VerifyType compiler intrinsic that can be used
by tests and fuzzers to generate a runtime type check of the given
input value. Internally, %VerifyType is lowered to %AssertType
which is why checks are currently limited to range types.

tests to be const-correct.

Drive-by: Add a few consts to NodeProperties accessors to allow
Bug: v8:11724
Change-Id: I06842062d0e8278a5ba011d5a09947fe05b6e85e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859959
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74377}
      f486a343
  71. 04 May, 2021 1 commit
  73. 23 Apr, 2021 1 commit
    • Nico Hartmann's avatar
      [TurboFan] Streamline BigInt.asUintN lowering · 98300313
      Nico Hartmann authored 
      This CL applies the following changes:
- JSCallReducer no longer generates a CheckBigInt in front of the
  generated BigIntAsUintN.
- This results in a slight change of the semantics of the latter, which
  now includes the necessary type check. Typer and Verifier are changed
  accordingly.
- The BigIntAsUintN operator is now effectful, since it can now deopt.
- IrOpcode::kBigIntAsUintN is now lowered in SimplifedLowering instead
  of EffectControlLinearizer, the necessary type check is introduced
  by the RepresentationChanger.
- Adds a small mjsunit test to check the correct deoptimization behavior
  of optimized BigInt.asUintN.
==> Remove UseInfo::TruncatingWord64()!

Drive-by: Fix an issue in ChangeUnaryToPureBinaryOp when the new_input
is at index 1.
Drive-by: Introduce an %Is64Bit() intrinsic to allow tests to
distinguish 32 and 64 bit architectures.

Bug: v8:11682
Change-Id: I448f892d3bd2280d731ae5b248c833de8faf1bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843816
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74147}
      98300313
  75. 13 Apr, 2021 1 commit