1. 26 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      Reland "[osr] Use the new OSR cache" · 91453880
      Jakob Gruber authored
      This is a reland of commit 91da3883
      
      Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      on arm64.
      
      Original change's description:
      > [osr] Use the new OSR cache
      >
      > This CL switches over our OSR system to be based on the feedback
      > vector osr caches.
      >
      > - OSRing to Sparkplug is fully separated from OSR urgency. If
      >   SP code exists, we simply jump to it, no need to maintain an
      >   installation request.
      > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      >   If a valid target code object exists, we enter it *without*
      >   calling into runtime to fetch the code object.
      > - Finally, OSR urgency still remains as the heuristic for
      >   requesting Turbofan OSR compile jobs. Note it no longer has a
      >   double purpose of being a generic untargeted installation
      >   request.
      >
      > With the new system in place, we can remove now-unnecessary
      > hacks:
      >
      > - Early OSR tierup is replaced by the standard OSR system. Any
      >   present OSR code is automatically entered.
      > - The synchronous OSR compilation fallback is removed. With
      >   precise installation (= per-JumpLoop-bytecode) we no longer
      >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      >   mismatches. Execution has moved on while compiling? Simply spawn
      >   a new concurrent compile job.
      > - Remove the synchronous (non-OSR) Turbofan compile request now
      >   that we always enter available OSR code as early as possible.
      > - Tiering into Sparkplug no longer messes with OSR state.
      >
      > Bug: v8:12161
      > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80147}
      
      Bug: v8:12161
      Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80167}
      91453880
  2. 25 Apr, 2022 2 commits
    • Nico Hartmann's avatar
      Revert "[osr] Use the new OSR cache" · c34b7b41
      Nico Hartmann authored
      This reverts commit 91da3883.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
      
      Original change's description:
      > [osr] Use the new OSR cache
      >
      > This CL switches over our OSR system to be based on the feedback
      > vector osr caches.
      >
      > - OSRing to Sparkplug is fully separated from OSR urgency. If
      >   SP code exists, we simply jump to it, no need to maintain an
      >   installation request.
      > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      >   If a valid target code object exists, we enter it *without*
      >   calling into runtime to fetch the code object.
      > - Finally, OSR urgency still remains as the heuristic for
      >   requesting Turbofan OSR compile jobs. Note it no longer has a
      >   double purpose of being a generic untargeted installation
      >   request.
      >
      > With the new system in place, we can remove now-unnecessary
      > hacks:
      >
      > - Early OSR tierup is replaced by the standard OSR system. Any
      >   present OSR code is automatically entered.
      > - The synchronous OSR compilation fallback is removed. With
      >   precise installation (= per-JumpLoop-bytecode) we no longer
      >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      >   mismatches. Execution has moved on while compiling? Simply spawn
      >   a new concurrent compile job.
      > - Remove the synchronous (non-OSR) Turbofan compile request now
      >   that we always enter available OSR code as early as possible.
      > - Tiering into Sparkplug no longer messes with OSR state.
      >
      > Bug: v8:12161
      > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80147}
      
      Bug: v8:12161
      Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@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@{#80148}
      c34b7b41
    • Jakob Gruber's avatar
      [osr] Use the new OSR cache · 91da3883
      Jakob Gruber authored
      This CL switches over our OSR system to be based on the feedback
      vector osr caches.
      
      - OSRing to Sparkplug is fully separated from OSR urgency. If
        SP code exists, we simply jump to it, no need to maintain an
        installation request.
      - Each JumpLoop checks its dedicated FeedbackVector cache slot.
        If a valid target code object exists, we enter it *without*
        calling into runtime to fetch the code object.
      - Finally, OSR urgency still remains as the heuristic for
        requesting Turbofan OSR compile jobs. Note it no longer has a
        double purpose of being a generic untargeted installation
        request.
      
      With the new system in place, we can remove now-unnecessary
      hacks:
      
      - Early OSR tierup is replaced by the standard OSR system. Any
        present OSR code is automatically entered.
      - The synchronous OSR compilation fallback is removed. With
        precise installation (= per-JumpLoop-bytecode) we no longer
        have the problem of 'getting unlucky' with JumpLoop/cache entry
        mismatches. Execution has moved on while compiling? Simply spawn
        a new concurrent compile job.
      - Remove the synchronous (non-OSR) Turbofan compile request now
        that we always enter available OSR code as early as possible.
      - Tiering into Sparkplug no longer messes with OSR state.
      
      Bug: v8:12161
      Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80147}
      91da3883
  3. 14 Apr, 2022 1 commit
  4. 13 Apr, 2022 2 commits
  5. 11 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      Reland "[osr] Add an install-by-offset mechanism" · b8473c52
      Jakob Gruber authored
      This is a reland of commit 51b99213
      
      Fixed in reland:
      - bytecode_age was incorrectly still accessed as an int8 (instead
        of int16).
      - age and osr state were incorrectly reset on ia32 (16-bit write
        instead of 32-bit).
      
      Original change's description:
      > [osr] Add an install-by-offset mechanism
      >
      > .. for concurrent OSR. There, the challenge is to hit the correct
      > JumpLoop bytecode once compilation completes, since execution has
      > moved on in the meantime.
      >
      > This CL adds a new mechanism to request installation at a specific
      > bytecode offset. We add a new `osr_install_target` field to the
      > BytecodeArray:
      >
      >   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
      >     osr_urgency: uint32: 3 bit;
      >     osr_install_target: uint32: 13 bit;
      >   }
      >
      >   // [...]
      >   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
      >   bytecode_age: uint16;  // Only 3 bits used.
      >   // [...]
      >
      > Note urgency and install target are packed into one 16 bit field,
      > we can thus merge both checks into one comparison within JumpLoop.
      > Note also that these fields are adjacent to the bytecode age; we
      > still reset both OSR state and age with a single (now 32-bit)
      > store.
      >
      > The install target is the lowest 13 bits of the bytecode offset.
      > When set, every reached JumpLoop will check `is this my offset?`,
      > and if yes, jump into runtime to tier up.
      >
      > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
      >
      > Bug: v8:12161
      > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79853}
      
      Bug: v8:12161
      Change-Id: I7c59b2a2aacb1d7d40fdf39396ec9d8d48b0b9ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578543Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79911}
      b8473c52
  6. 07 Apr, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "[osr] Add an install-by-offset mechanism" · bb5cc0d5
      Leszek Swirski authored
      This reverts commit 51b99213.
      
      Reason for revert: Speculative revert for MSAN failure  https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/43080/overview
      
      Original change's description:
      > [osr] Add an install-by-offset mechanism
      >
      > .. for concurrent OSR. There, the challenge is to hit the correct
      > JumpLoop bytecode once compilation completes, since execution has
      > moved on in the meantime.
      >
      > This CL adds a new mechanism to request installation at a specific
      > bytecode offset. We add a new `osr_install_target` field to the
      > BytecodeArray:
      >
      >   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
      >     osr_urgency: uint32: 3 bit;
      >     osr_install_target: uint32: 13 bit;
      >   }
      >
      >   // [...]
      >   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
      >   bytecode_age: uint16;  // Only 3 bits used.
      >   // [...]
      >
      > Note urgency and install target are packed into one 16 bit field,
      > we can thus merge both checks into one comparison within JumpLoop.
      > Note also that these fields are adjacent to the bytecode age; we
      > still reset both OSR state and age with a single (now 32-bit)
      > store.
      >
      > The install target is the lowest 13 bits of the bytecode offset.
      > When set, every reached JumpLoop will check `is this my offset?`,
      > and if yes, jump into runtime to tier up.
      >
      > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
      >
      > Bug: v8:12161
      > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79853}
      
      Bug: v8:12161
      Change-Id: I0c47499544465c80b5b23a492c00ec1c62815caa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576121
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@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@{#79855}
      bb5cc0d5
    • Jakob Gruber's avatar
      [osr] Add an install-by-offset mechanism · 51b99213
      Jakob Gruber authored
      .. for concurrent OSR. There, the challenge is to hit the correct
      JumpLoop bytecode once compilation completes, since execution has
      moved on in the meantime.
      
      This CL adds a new mechanism to request installation at a specific
      bytecode offset. We add a new `osr_install_target` field to the
      BytecodeArray:
      
        bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
          osr_urgency: uint32: 3 bit;
          osr_install_target: uint32: 13 bit;
        }
      
        // [...]
        osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
        bytecode_age: uint16;  // Only 3 bits used.
        // [...]
      
      Note urgency and install target are packed into one 16 bit field,
      we can thus merge both checks into one comparison within JumpLoop.
      Note also that these fields are adjacent to the bytecode age; we
      still reset both OSR state and age with a single (now 32-bit)
      store.
      
      The install target is the lowest 13 bits of the bytecode offset.
      When set, every reached JumpLoop will check `is this my offset?`,
      and if yes, jump into runtime to tier up.
      
      Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
      
      Bug: v8:12161
      Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79853}
      51b99213
  7. 17 Mar, 2022 1 commit
  8. 10 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Revert "[compiler] Don't remove OSR code cache if deoptimizing at out of loop" · 87f80671
      Jakob Gruber authored
      This reverts commit 190b5d95.
      
      Reason for revert: We should understand & fix regressions, see crbug.com/1304870#c9.
      
      Original change's description:
      > [compiler] Don't remove OSR code cache if deoptimizing at out of loop
      >
      > The main purpose of OSR compilation is fasten inner loop execution, the
      > OSR code cache is still correct for loop if optimizing at out of loop,
      > keep OSR code cache can reduce unnecessary slow bytecode execution with
      > feedback collection and avoid re-OSR compilation.
      > This CL can improve JetStream2 case navier-stokes by ~6%.
      >
      > Change-Id: I9518317fb922071b131cab5b56998a0fc198804a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Tao Pan <tao.pan@intel.com>
      > Cr-Commit-Position: refs/heads/main@{#79413}
      
      Bug: chromium:1304870
      Change-Id: I8791edc34b66ef9dd0b477d3e340e85b0617ef59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3515732
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79435}
      87f80671
  9. 09 Mar, 2022 1 commit
  10. 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
  11. 04 Mar, 2022 1 commit
    • Leszek Swirski's avatar
      [runtime] Fix sandboxing violation in CopyDataPropertiesWithExclProp · d05a38f9
      Leszek Swirski authored
      The newly optimised CopyDataPropertiesWithExcludedProperties acceses the
      excluded properties directly on the stack, to avoid pushing them twice.
      This meant that we had to pass a stack pointer into the runtime, which
      we couldn't do directly because all arguments to runtime functions
      should be tagged.
      
      We tried to work around this by passing the stack pointer in a Foreign,
      but this violated the V8 sandbox. Fortunately, the stack pointer is
      aligned, so it looks like a Smi to the GC. So, we can pass it directly
      on the stack as a runtime argument but doing a bit of bitcasting.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
      Bug: v8:11614
      Change-Id: I87c4a34a15ae863277142aa29f48b1dd546014e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497745
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79369}
      d05a38f9
  12. 03 Mar, 2022 1 commit
  13. 23 Feb, 2022 1 commit
  14. 17 Jan, 2022 1 commit
  15. 02 Dec, 2021 1 commit
  16. 30 Nov, 2021 1 commit
  17. 29 Oct, 2021 1 commit
  18. 28 Oct, 2021 1 commit
  19. 18 Oct, 2021 3 commits
  20. 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
  21. 11 Oct, 2021 1 commit
  22. 07 Sep, 2021 1 commit
  23. 06 Sep, 2021 1 commit
  24. 27 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      [sparkplug] Clobber accumulator in StaGlobal · 732f394c
      Leszek Swirski authored
      StaGlobal didn't write the accumulator, but the baseline implementation
      assumed that it could preserve the accumulator by taking the return
      value of the StoreGlobalIC. This almost always worked, except for
      setters on the global object.
      
      Fix this by marking StaGlobal as clobbering the accumulator, same as
      StaNamedProperty (StaNamedProperty needs to do this anyway to avoid
      inlined setters from needing to create accumulator-preserving frames;
      StaGlobal would have needed the same thing if we'd ever inlined setters
      for it).
      
      Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the
      baseline compiler, which checks if the accumulator value is preserved
      across non-accumulator-writing bytecodes. This found a (benign) bug with
      ForInPrepare, so fix that too.
      
      Fixed: chromium:1242306
      Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76525}
      732f394c
  25. 16 Aug, 2021 1 commit
  26. 12 Aug, 2021 1 commit
  27. 10 Aug, 2021 1 commit
  28. 06 Aug, 2021 1 commit
    • Victor Gomes's avatar
      [baseline] Update EstimateInstructionSize · 63be6dde
      Victor Gomes authored
      Adds a minimum estimated size.
      
      Data suggests that estimated instruction size (+ relocation info size)
      is linear to bytecode array length. This CL adds a constant for this
      equation. The ratio remains the same.
      
      This is important, because we want to increase success rate of
      estimation when compiling on-heap.
      
      When off-heap, we round up the assembler buffer to 4kB, so this CL
      will only impact JS functions with more than 585 bytecodes, i.e, the
      new added constant will be negligible.
      
      Note: Relocation info (for Sparkplug) is usually so small that it is
      not useful to have a separate zone for this.
      
      Bug: v8:11872
      Change-Id: I789e72f80b970d1f541965e7ae808b61c8174326
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069155
      Auto-Submit: Victor Gomes <victorgomes@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76144}
      63be6dde
  29. 23 Jul, 2021 1 commit
    • Leszek Swirski's avatar
      [ignition/sparkplug] Fix folded interrupt check · ef17601f
      Leszek Swirski authored
      Change the folded interrupt check to be on JumpLoop only, to avoid
      calling it from Return. The call from Return could cause spurious stack
      overflows, which interacted poorly with async functions that had already
      resolved their promise.
      
      Now the bytecode budget interrupt function is split into two functions,
      one which does the stack check and one which doesn't. The former is
      still called from JumpLoop, the latter is called from Return.
      
      Bug: chromium:1231952, chromium:1232105
      Change-Id: I8c4e2937f64b5f8fdbd6c1fcb2a76ec5f090ae3c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049076Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75891}
      ef17601f
  30. 22 Jul, 2021 1 commit
  31. 20 Jul, 2021 1 commit
  32. 19 Jul, 2021 1 commit
  33. 08 Jul, 2021 3 commits