1. 04 Apr, 2022 3 commits
    • Jakob Gruber's avatar
      Reland "Address comments from `[osr] Basic support for concurrent OSR`" · 66f8f20a
      Jakob Gruber authored
      - Unhandlify OSROptimizedCodeCache::GetOptimizedCode.
      - Unstatic-fy FeedbackVector::SetOptimizedCode.
      - Remove frame-walking logic during the OSR tierup decision.
      
      The reland is unchanged from the original CL.
      
      Bug: v8:12161
      Change-Id: Ibf03a9dd9a6fcd38c0664e5d5014a26d0240e035
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568463Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79752}
      66f8f20a
    • Jakob Gruber's avatar
      Reland "[osr] Basic support for concurrent OSR" · d187c6c2
      Jakob Gruber authored
      This is a reland of commit 3ce690ee
      
      Changed for the reland:
      - Remove the currently-unused BytecodeArray member to avoid MSAN
        failures.
      - s/return/continue/ in optimizing-compile-dispatcher.
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161
      Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79746}
      d187c6c2
    • Jakob Gruber's avatar
      [deoptimizer] Remove soft deopts · 1ff685d8
      Jakob Gruber authored
      .. since they are the same as eager deopts (% an unused counter).
      
      Fixed: v8:12765
      Change-Id: I2be6210e476ead4ac6629a49259f28321e965867
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565717Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79729}
      1ff685d8
  2. 01 Apr, 2022 2 commits
    • Adam Klein's avatar
      Revert "[osr] Basic support for concurrent OSR" · 32f28553
      Adam Klein authored
      This reverts commit 3ce690ee.
      
      Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161, chromium:1312188
      Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983
      Auto-Submit: Adam Klein <adamk@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79702}
      32f28553
    • Adam Klein's avatar
      Revert "Address comments from `[osr] Basic support for concurrent OSR`" · ef83c9e8
      Adam Klein authored
      This reverts commit dc9b48e4.
      
      Reason for revert: https://crbug.com/1312188
      
      Original change's description:
      > Address comments from `[osr] Basic support for concurrent OSR`
      >
      > - Unhandlify OSROptimizedCodeCache::GetOptimizedCode.
      > - Unstatic-fy FeedbackVector::SetOptimizedCode.
      > - Remove frame-walking logic during the OSR tierup decision.
      >
      > Bug: v8:12161
      > Change-Id: I4fa8c972cb50d369b17898ba57e1909c86e933df
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560478
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79686}
      
      Bug: v8:12161, chromium:1312188
      Change-Id: Ia64c4204f9f65f19aa858c61f32658cee310033e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564990
      Auto-Submit: Adam Klein <adamk@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@{#79701}
      ef83c9e8
  3. 31 Mar, 2022 3 commits
    • Joyee Cheung's avatar
      [ic] name Set/Define/Store property operations more consistently pt.2 · cf5ce194
      Joyee Cheung authored
      As a follow-up of
      https://chromium-review.googlesource.com/c/v8/v8/+/3481475,
      this renames a few more operations related to property stores to keep
      them consistent and adds comments to explain about what they do.
      
      Summary of the renamed identifiers:
      
      - SetPropertyInLiteral -> CreateDataProperty: this implements
        [[CreateDataProperty]] in the spec which does [[DefineOwnProperty]]
        instead of [[Set]], so rename for clarity.
      - IsStoreIC(), IsStoreICKind() -> IsSetNamedIC(), IsSetNamedICKind():
        these only check whether the feedback kind is kSetNamedSloppy or
        kSetNamedStrict, so the scope can be narrowed.
      - StoreMode::kOrdinary -> StoreMode::kSet: this implements [[Set]]
        in the spec and is used by both KeyedStoreIC and
        StoreIC to set the properties when there is no feedback.
      - StoreMode::kInLiteral -> StoreMode::kDefineKeyedOwnInLiteral:
        this implements [[CreateDataProperty]] while expecting the receiver
        to be a JSObject created by us (the `InLiteral` part). Prepend
        `DefineKeyedOwn` to it so that it's more aligned with other
        StoreModes - it should be possible to just merge this into the
        more generic StoreMode::kDefineKeyedOwn later.
      - KeyedStoreGenericAssembler::SetProperty ->
        KeyedStoreGenericAssembler::StoreProperty: these helpers are used by
        both define and set operations, distinguished with the StoreMode,
        so rename it to the more generic StoreProperty.
      
      Bug: v8:12548
      Change-Id: Iccef673c1dc707bbdbf010f02f7db1e9ec32b3e4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557690Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79694}
      cf5ce194
    • Jakob Gruber's avatar
      Address comments from `[osr] Basic support for concurrent OSR` · dc9b48e4
      Jakob Gruber authored
      - Unhandlify OSROptimizedCodeCache::GetOptimizedCode.
      - Unstatic-fy FeedbackVector::SetOptimizedCode.
      - Remove frame-walking logic during the OSR tierup decision.
      
      Bug: v8:12161
      Change-Id: I4fa8c972cb50d369b17898ba57e1909c86e933df
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560478Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79686}
      dc9b48e4
    • Jakob Gruber's avatar
      [osr] Basic support for concurrent OSR · 3ce690ee
      Jakob Gruber authored
      This CL adds basic support behind --concurrent-osr,
      disabled by default.
      
      When enabled:
      1) the first OSR request starts a concurrent OSR compile job.
      2) on completion, the code object is inserted into the OSR cache.
      3) the next OSR request picks up the cached code (assuming the request
         came from the same JumpLoop bytecode).
      
      We add a new osr optimization marker on the feedback vector to
      track whether an OSR compile is currently in progress.
      
      One fundamental issue remains: step 3) above is not guaranteed to
      hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      be installed. This will be addressed in a followup by targeting
      specific bytecode offsets for the install request.
      
      This change is based on fanchen.kong@intel.com's earlier
      change crrev.com/c/3369361, thank you!
      
      Bug: v8:12161
      Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79685}
      3ce690ee
  4. 30 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Refactor OptimizationMarker and ConcurrencyMode enums · 57d985a5
      Jakob Gruber authored
      .. with readability and simplicity in mind.
      
      - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering'
        also matches 'TieringManager' terminology.
      - Rename the values:
        kNone -> kNone
        kInOptimizationQueue -> kInProgress
        kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous
        kCompileFoo_Concurrent -> kRequestFoo_Concurrent
      - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous.
      - Add predicates to test enum values.
      - Consistent lower case names for accessors on JSFunction and
        FeedbackVector.
      - Instead of having to call HasOptimizationMarker() before using any
        other accessor, simply have optimization_marker() return kNone if
        no feedback vector exists.
      - Drive-by: Enable the Unreachable() in MaybeOptimizeCode()
        unconditionally - this should never happen, there's no reason not
        to protect against this in release builds as well.
      
      Bug: v8:12161
      Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79669}
      57d985a5
  5. 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
  6. 02 Mar, 2022 1 commit
  7. 01 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Refactor tiering-related JSFunction methods · aad3e727
      Jakob Gruber authored
      - Add the Isolate as an explicit param (we already have it at all
        callsites)
      - Pass an explicit CodeKind param to MarkForOptimization in preparation
        for Maglev.
      - Split EnsureFeedbackVector into that, plus
        CreateAndAttachFeedbackVector for when we know it has to be created.
      
      Bug: v8:7700
      Change-Id: Ie9022deccd31d472d6df3d442b25583af5569ab0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497383
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79318}
      aad3e727
  8. 15 Feb, 2022 1 commit
    • Jakob Gruber's avatar
      Remove the OptimizationTier enum · 8bad4516
      Jakob Gruber authored
      This was mostly unused. We should simply be able to use CodeKind plus
      related predicates instead.
      
      Replace FeedbackVector::optimization_tier with
      maybe_has_optimized_code, which states whether the optimized code
      cache is filled. The value is updated lazily and may lag behind the
      actual code cache state. We only use this field for quick cache-empty?
      checks from generated code.
      
      Bug: v8:7700,v8:12552
      Change-Id: Ibfc5c0128eac56167a68ecba5690eab2e9369640
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460741Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79107}
      8bad4516
  9. 27 Jan, 2022 1 commit
  10. 21 Jan, 2022 2 commits
  11. 20 Jan, 2022 1 commit
  12. 17 Jan, 2022 1 commit
  13. 14 Dec, 2021 1 commit
  14. 19 Nov, 2021 1 commit
  15. 17 Nov, 2021 1 commit
  16. 09 Nov, 2021 1 commit
  17. 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
  18. 12 Oct, 2021 1 commit
  19. 11 Oct, 2021 1 commit
    • Nico Weber's avatar
      Fix Wbitwise-instead-of-logical warnings · bc4ea5e0
      Nico Weber authored
      `a && b` only evaluates b if a is true. `a & b` always evaluates
      both a and b. If a and b are of type bool, `&&` is usually what you
      want, so clang now warns on `&` where both arguments are of type bool.
      
      This warning fires twice in v8.
      
      1. In branch-elimination.cc, we have the rare case where we _want_
         to evaluate both branches so that both reduced_ and node_conditions_
         are always updated. To make this more obvious, reorder the code a
         bit. (The warning can also be suppressed by casting one of the two
         expressions to int, but the reordering seems clearer.)
      
      2. The other case is an actual (inconsequential) typo, so use || here.
      
      Bug: chromium:1255745
      Change-Id: I62ba45451ee2642265574d28c646d85f5a18670b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212891
      Auto-Submit: Nico Weber <thakis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77314}
      bc4ea5e0
  20. 21 Sep, 2021 1 commit
  21. 16 Aug, 2021 1 commit
  22. 11 Aug, 2021 1 commit
  23. 03 Aug, 2021 1 commit
  24. 23 Jul, 2021 1 commit
  25. 01 Jul, 2021 1 commit
  26. 18 Jun, 2021 1 commit
  27. 17 Jun, 2021 1 commit
  28. 14 Jun, 2021 1 commit
  29. 07 Jun, 2021 1 commit
  30. 27 May, 2021 1 commit
  31. 06 May, 2021 1 commit
    • Fanchen Kong's avatar
      Collect receiver to feedback for prototype.apply · 519c82ce
      Fanchen Kong authored
      When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
      	receiver.apply(this, args) ->
      	this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
      is not a heapconstant.
      
      With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.
      
      function reduceArray(func, arr, r) {
          for (var i = 0, len = arr.length; i < len; i++) {
                  r = func.apply(null, r, arr[i]);
          }
          return r;
      }
      
      var a = 0; for (var i = 0; i < 10000000; i++) {
          a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
      }
      console.log(a);
      
      This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.
      
      Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
      Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74413}
      519c82ce
  32. 04 May, 2021 1 commit
  33. 26 Apr, 2021 1 commit
  34. 20 Apr, 2021 1 commit
    • Sathya Gunasekaran's avatar
      Reland "[ic] Add a new MegaDOM IC" · fbd114bd
      Sathya Gunasekaran authored
      This is a reland of c83c9590
      
      Changes since revert: nothing, issue was crbug.com/v8/11666
      
      Original change's description:
      > [ic] Add a new MegaDOM IC
      >
      > This patch implements the MegaDOM IC setup and access. A new MegaDOM
      > IC state indicates that we've seen only DOM accessors at this access
      > site.
      >
      > This CL only adds support for DOM getters in LoadIC, other kinds of
      > access will be added in follow on CLs.
      >
      > Still remaining TODO before shipping:
      > 1. Have a mechanism to invalidate the protector
      > 2. Have a mechanism to find the accessors that aren't overloaded
      > 3. Use a new builtin to miss to runtime on access check failure
      >
      > Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
      > Bug: v8:11321
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73733}
      
      Bug: v8:11321
      Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74056}
      fbd114bd