1. 20 Apr, 2022 1 commit
  2. 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
  3. 16 Dec, 2021 1 commit
  4. 11 Nov, 2021 2 commits
    • Ng Zhi An's avatar
      [numbers] Rename ConversionFlags:NO_FLAG to NO_CONVERSION_FLAGS · 4edbdee1
      Ng Zhi An authored
      This fixes a -Wshadow warning for NO_FLAG. The other option is to
      make it an enum class, which makes test-conversions.cc a bit verbose.
      
      Bug: v8:12244,v8:12245
      Change-Id: I3ea429eb45e31b25d4c6658ceb86c33ba280ae51
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3274015Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77860}
      4edbdee1
    • Leszek Swirski's avatar
      [interpreter] Fix block resurrection by LoopHeader · 18b63625
      Leszek Swirski authored
      Loop headers in the interpreter would start a new basic block, which
      among other things would reset the liveness of that block. This meant
      that a loop created after dead code, without a check for whether the
      code is currently dead or not, would "resurrect" that block's liveness,
      making the inside of the loop live even though the loop itself is
      unreachable.
      
      This works fine, since the loop is still unreachable, but can breaks
      DCHECKs in bytecode liveness analysis for cases where a register is
      supposed to be initialised before the loop, in the dead code, and is
      then used inside the loop, in the resurrected code.
      
      Normally this wouldn't be a problem, since blocks are normally killed on
      the statement level and we check for deadness during statement
      iteration, but `foo() = x` introduces an expression-level block killer
      (being re-written to `foo[throw ReferenceError] = x`) and we don't check
      for deadness after assignment Lhs preparation.
      
      This does mean that we have to fix the InterpreterJumps test, to not try
      to jump into the middle of a loop (since this could revive the loop).
      This can only happen when manually creating bytecode, bytecode generated
      from JavaScript is always reducible.
      
      Bug: chromium:1230597
      Change-Id: I8403ccdeae7e5450adf629026e2ca8a134c81877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275557
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77846}
      18b63625
  5. 08 Nov, 2021 1 commit
  6. 17 Jun, 2021 1 commit
  7. 14 Jun, 2021 1 commit
  8. 07 Jun, 2021 1 commit
  9. 25 Mar, 2021 1 commit
  10. 24 Feb, 2021 1 commit
  11. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored
      This is a reland of cf93071c
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  12. 16 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored
      This reverts commit cf93071c.
      
      Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      
      This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      that we can use a single byte to represent the common operation of
      storing to a low-numbered register. This generally reduces the quantity
      of bytecode generated on web sites by 8-9%.
      
      In order to not degrade speed, a couple of other changes are required:
      
      The existing lookahead logic to check for Star after certain other
      bytecode handlers is updated to check for these new short Star codes
      instead. Furthermore, that lookahead logic is updated to contain its own
      copy of the dispatch jump rather than merging control flow with the
      lookahead-failed case, to improve branch prediction.
      
      A bunch of constants use bytecode size in bytes as a proxy for the size
      or complexity of a function, and are adjusted downward proportionally to
      the decrease in generated bytecode size.
      
      Other small drive-by fix: update generate-bytecode-expectations to emit
      \n instead of \r\n on Windows.
      
      Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
  13. 11 Feb, 2021 1 commit
  14. 10 Feb, 2021 2 commits
  15. 17 Dec, 2020 1 commit
  16. 11 Nov, 2020 1 commit
  17. 03 Nov, 2020 1 commit
  18. 02 Nov, 2020 1 commit
  19. 28 May, 2020 1 commit
    • Nico Hartmann's avatar
      Reland "[turbofan] Improve equality on NumberOrOddball" · 120d4333
      Nico Hartmann authored
      This is a reland of 6204768b
      
      The original issue exposed the problem that NumberEqual performs
      implicit conversion of oddballs to numbers, which is incorrect for
      abstract equality comparison (i.e. 0 == null must not be true).
      
      This reland fixes this by applying the following steps:
      * Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
        CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
      * In CodeStubAssembler::Equal: Further distinguish between boolean and
        non-boolean oddballs and set feedback accoringly.
      * In JSTypedLowering: Construct [Speculative]NumberEqual operator with
        CompareOperationHint::kNumberOrBoolean, when this feedback is present.
        JSOperatorBuilder and operator cache are extended accordingly.
      * In SimplifiedLowering: Propagate a UseInfo with new
        TypeCheckKind::kNumberOrBoolean.
      * This leads to the generation of CheckedTaggedToFloat64 in
        RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
      * In EffectControlLinearizer: Handle this new mode. Accept and convert
        number and boolean and deopt for rest.
      
      Original change's description:
      > [turbofan] Improve equality on NumberOrOddball
      >
      > This CL cleans up CompareOperationFeedback by replacing it with a
      > composable set of flags. The interpreter is changed to collect
      > more specific feedback for abstract equality, especially if oddballs
      > are involved.
      >
      > TurboFan is changed to construct SpeculativeNumberEqual operator
      > instead of the generic JSEqual in many more cases. This change has
      > shown a local speedup of a factor of 3-10, because the specific
      > operator is way faster than calling into the generic builtin, but
      > it also enables additional optimizations, further improving
      > runtime performance.
      >
      > Bug: v8:5660
      > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67645}
      
      TBR: tebbi@chromium.org
      Bug: v8:5660
      Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68037}
      120d4333
  20. 12 May, 2020 1 commit
    • Milad Farazmand's avatar
      Revert "s390: [arm] Add missing RELATIVE_CODE_TARGET iteration" · b5939c75
      Milad Farazmand authored
      This reverts commit 9d3cca1c.
      
      Reason for revert: Only the test needs to be skipped on s390. Refer to this: https://crrev.com/c/1981505
      
      Original change's description:
      > s390: [arm] Add missing RELATIVE_CODE_TARGET iteration
      > 
      > Port b766299d
      > Port 9592b043
      > Port d915b8d6
      > 
      > Original Commit Message:
      > 
      >     Code object iteration was missing logic for RELATIVE_CODE_TARGET
      >     reloc entries. Garbage collection could thus miss objects that were
      >     referenced only as targets of pc-relative calls or jumps.
      > 
      >     RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
      >     at mksnapshot-time.
      > 
      >     This exposed another issue in that the interpreter entry trampoline
      >     copy we generate for profiling *did* contain relative calls in
      >     runtime-accessible code. This is a problem, since code space on arm is,
      >     by default, too large to be fully addressable through pc-relative
      >     calls. This CL thus also disables the related
      >     FLAG_interpreted_frames_native_stack feature on arm.
      > 
      >     objects.
      > 
      > R=​jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      > BUG=
      > LOG=N
      > 
      > Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
      > Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      > Cr-Commit-Position: refs/heads/master@{#66644}
      
      TBR=michael_dawson@ca.ibm.com,mlippautz@chromium.org,jyan@ca.ibm.com,jgruber@chromium.org,joransiu@ca.ibm.com,miladfar@ca.ibm.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id645a9def23d278235ff77f25249d2187e8105ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196521Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#67751}
      b5939c75
  21. 08 May, 2020 1 commit
    • Nico Hartmann's avatar
      Revert "[turbofan] Improve equality on NumberOrOddball" · f4b98cc6
      Nico Hartmann authored
      This reverts commit 6204768b.
      
      Reason for revert: A number of Clusterfuzz reports (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1079474)
      
      Original change's description:
      > [turbofan] Improve equality on NumberOrOddball
      > 
      > This CL cleans up CompareOperationFeedback by replacing it with a
      > composable set of flags. The interpreter is changed to collect
      > more specific feedback for abstract equality, especially if oddballs
      > are involved.
      > 
      > TurboFan is changed to construct SpeculativeNumberEqual operator
      > instead of the generic JSEqual in many more cases. This change has
      > shown a local speedup of a factor of 3-10, because the specific
      > operator is way faster than calling into the generic builtin, but
      > it also enables additional optimizations, further improving
      > runtime performance.
      > 
      > Bug: v8:5660
      > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67645}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org,nicohartmann@chromium.org
      
      Change-Id: I3410310ed2b1ff2eaee70c1b91c3151d35866108
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5660
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190414Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67673}
      f4b98cc6
  22. 07 May, 2020 1 commit
    • Nico Hartmann's avatar
      [turbofan] Improve equality on NumberOrOddball · 6204768b
      Nico Hartmann authored
      This CL cleans up CompareOperationFeedback by replacing it with a
      composable set of flags. The interpreter is changed to collect
      more specific feedback for abstract equality, especially if oddballs
      are involved.
      
      TurboFan is changed to construct SpeculativeNumberEqual operator
      instead of the generic JSEqual in many more cases. This change has
      shown a local speedup of a factor of 3-10, because the specific
      operator is way faster than calling into the generic builtin, but
      it also enables additional optimizations, further improving
      runtime performance.
      
      Bug: v8:5660
      Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67645}
      6204768b
  23. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [parser] Move Compiler::Analyze into Parser · 65d738d4
      Leszek Swirski authored
      Move rewriting, scope analysis, and internalization, to be unconditional
      operations done after parsing rather than a separate compile phase. This
      removes some of the complexity about rememberering when to call
      Compiler::Analyze, and makes these paths a bit more uniform.
      
      Also, forbid allocating any more AST strings after AstValueFactory
      internalization, by nulling out the Zone. Add an InternalizePartial
      method which doesn't null out the zone for those cases where we do want
      to be able to allocate after internalizing (e.g. internalization before
      scope analysis).
      
      Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67608}
      65d738d4
  24. 20 Mar, 2020 1 commit
  25. 16 Mar, 2020 1 commit
  26. 10 Mar, 2020 1 commit
    • Milad Farazmand's avatar
      s390: [arm] Add missing RELATIVE_CODE_TARGET iteration · 9d3cca1c
      Milad Farazmand authored
      Port b766299d
      Port 9592b043
      Port d915b8d6
      
      Original Commit Message:
      
          Code object iteration was missing logic for RELATIVE_CODE_TARGET
          reloc entries. Garbage collection could thus miss objects that were
          referenced only as targets of pc-relative calls or jumps.
      
          RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
          at mksnapshot-time.
      
          This exposed another issue in that the interpreter entry trampoline
          copy we generate for profiling *did* contain relative calls in
          runtime-accessible code. This is a problem, since code space on arm is,
          by default, too large to be fully addressable through pc-relative
          calls. This CL thus also disables the related
          FLAG_interpreted_frames_native_stack feature on arm.
      
          objects.
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66644}
      9d3cca1c
  27. 02 Mar, 2020 1 commit
  28. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  29. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  30. 15 Nov, 2019 1 commit
  31. 10 Sep, 2019 1 commit
  32. 19 Jul, 2019 1 commit
  33. 08 Jul, 2019 1 commit
  34. 30 May, 2019 1 commit
  35. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  36. 24 May, 2019 1 commit
  37. 23 May, 2019 1 commit