1. 20 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Begin porting ScopeInfo to Torque · ecaac329
      Seth Brenith authored
      This change adds Torque field definitions for ScopeInfo and begins to
      use the Torque-generated accessors in some places. It does not change
      the in-memory layout of ScopeInfo.
      
      Torque compiler changes:
      
      - Fix an issue where the parser created constexpr types for classes
        based on the class name rather than the `generates` clause. This meant
        that generated accessors referred to the imaginary type HashTable
        rather than the real C++ type FixedArray.
      - Don't pass Isolate* through the generated runtime functions that
        implement Torque macros. Maybe we'll need it eventually, but we don't
        right now and it complicates a lot of things.
      - Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
        Instead, emit a member function `SomeFieldOffset()` which fetches the
        slice for some_field and returns its offset.
      - Emit an `AllocatedSize()` member function for classes which have
        complex length expressions. It fetches the slice for the last field
        and performs the multiply&add to compute the total object size.
      - Emit field accessors for fields with complex length expressions, using
        the new offset functions.
      - Fix a few minor bugs where Torque can write uncompilable code.
      
      With this change, most code still treats ScopeInfo like a FixedArray, so
      I would like to follow up with some additional changes:
      
      1. Generate a GC visitor for ScopeInfo and use it
      2. Generate accessors for struct-typed fields (indexed or otherwise),
         and use them
      3. Get rid of the FixedArray-style get and set accessors; use
         TaggedField::load and similar instead
      4. Inherit from HeapObject rather than FixedArrayBase to remove the
         unnecessary `length` field
      
      After that, there will only be one ugly part left: initialization. I
      think it's possible to generate a factory function that takes a bunch of
      iterator parameters and returns a fully-formed, verifiably correct
      ScopeInfo instance, but doing so is more complicated than the four
      mostly-mechanical changes listed above.
      
      Bug: v8:7793
      Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72187}
      ecaac329
  2. 19 Jan, 2021 1 commit
  3. 04 Dec, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] uniform flattening and string access in Torque · 65d2c4b4
      Tobias Tebbi authored
      Port String::Flatten to Torque (using a fast C call for the
      non-allocating part) and provide fast and easy access to sequential
      string data in Torque: GetStringData() flattens if necessary and
      computes slices that allow direct access.
      
      Applications: String.prototype.replaceAll, String.prototype.endsWith,
        and String.prototype.beginsWith now use GetStringData() and direct
        slice access instead of the slow StringCharCodeAt and they no
        longer bail out to the runtime for flattening.
      
      Drive-by changes:
        - Expose String instance type bits as bitfields and enums in Torque.
        - Fix method lookup in Torque to include superclass methods.
        - Use char8 and char16 types in more places.
        - Allow fast C calls with void return type.
        - Add Torque macros to create subslices.
        - Add no-GC scopes to runtime functions loading external string data.
      
      
      Bug: v8:7793
      Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71611}
      65d2c4b4
  4. 01 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [Turboprop] Move deoptimizations for dynamic map checks into builtin. · b6643320
      Ross McIlroy authored
      In order to reduce the codegen size of dynamic map checks, add the
      ability to have an eager with resume deopt point, which can call
      a given builitin to perform a more detailed check than can be done
      in codegen, and then either deoptimizes itself (as if the calling
      code had performed an eager deopt) or resumes execution in the
      calling code after the check.
      
      In addition, support for adding extra arguments to a
      deoptimization continuation is added to enable us to pass the
      necessary arguments to the DynamicMapChecks builtin.
      
      Finally, a trampoline is added to the DynamicMapChecks which saves
      the registers that might be clobbered by that builtin, to avoid
      having to save them in the generated code. This trampoline also
      performs the deoptimization based on the result of the
      DynamicMapChecks builtin.
      
      In order to ensure both the trampoline and DynamicMapChecks
      builtin have the same call interface, and to limit the number
      of registers that need saving in the trampoline, the
      DynamicMapChecks builtin is moved to be a CSA builtin with a
      custom CallInterfaceDescriptor, that calls an exported Torque
      macro that implements the actual functionality.
      
      All told, this changes the codegen for a monomorphic dynamic
      map check from:
          movl rbx,<expected_map>
          cmpl [<object>-0x1],rbx
          jnz <deferred_call>
         resume_point:
          ...
         deferred_call:
          <spill registers>
          movl rax,<slot>
          movq rbx,<object>
          movq rcx,<handler>
          movq r10,<DynamicMapChecks>
          call r10
          cmpq rax,0x0
          jz <restore_regs>
          cmpq rax,0x1
          jz <deopt_point_1>
          cmpq rax,0x2
          jz <deopt_point_2>
          int3l
         restore_regs:
          <restore_regs>
          jmp <resume_point>
          ...
         deopt_point_1:
          call Deoptimization_Eager
         deopt_point_2:
          call Deoptimization_Bailout
      
      To: movl rax,<slot>
          movl rcx,<expected_map>
          movq rdx,<handler>
          cmpl [<object>-0x1],rcx
          jnz <deopt_point>
         resume_point:
          ...
         deopt_point:
          call DynamicMapChecksTrampoline
          jmp <resume_point>
      
      BUG=v8:10582
      
      Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71545}
      b6643320
  5. 30 Nov, 2020 1 commit
  6. 20 Nov, 2020 4 commits
  7. 19 Nov, 2020 1 commit
  8. 13 Nov, 2020 1 commit
  9. 12 Nov, 2020 1 commit
  10. 11 Nov, 2020 1 commit
  11. 09 Nov, 2020 2 commits
  12. 06 Nov, 2020 4 commits
  13. 03 Nov, 2020 1 commit
  14. 29 Oct, 2020 1 commit
  15. 20 Oct, 2020 1 commit
    • Marja Hölttä's avatar
      [super ic] Fix receiver type · 3773e46e
      Marja Hölttä authored
      With non-super loads (receiver == lookup_start_object), we don't hit
      the code in AccessorAssembler::GenericPropertyLoad calling
      CSA::TryGetOwnProperty if the receiver (the lookup_start_object) is a
      SMI.
      
      But with super property loads, if we set up lookup_start_object the
      right way, we will hit this code.
      
      The code was assuming receiver is a HeapObject, which is too
      restrictive. The receiver is only used for the accessor call, so
      it's ok to make the type more generic.
      
      Bug: v8:9237, chromium:1139786
      Change-Id: I3167ccfb54a49ac1c401040a6f02fc1f3b98d9d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484366Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70647}
      3773e46e
  16. 19 Oct, 2020 1 commit
  17. 16 Oct, 2020 1 commit
  18. 14 Oct, 2020 2 commits
  19. 13 Oct, 2020 3 commits
    • Igor Sheludko's avatar
      Reland^2 "[csa] Fix semantics of PopAndReturn" · d2ab873d
      Igor Sheludko authored
      This is a reland of 3593ee83
      
      The MSAN doesn't seem to be considering initializing stores via inline
      assembly as such (in a new cctest helper GetStackPointer()), so this
      reland attempt fixes the issue and ensures that the MSAN bot is happy.
      
      Original change's description:
      > Reland "[csa] Fix semantics of PopAndReturn"
      >
      > This is a reland of 5e5eaf79
      >
      > This CL fixes the "function returns address of local variable" issue
      > which GCC was complaining about by using inline assembly instead of
      > address of a local for getting stack pointer approximation.
      >
      > Original change's description:
      > > [csa] Fix semantics of PopAndReturn
      > >
      > > This CL prohibits using PopAndReturn from the builtins that
      > > have calling convention with arguments on the stack.
      > >
      > > This CL also updates the PopAndReturn tests so that even off-by-one
      > > errors in the number of poped arguments are caught which was not the
      > > case before.
      > >
      > > Motivation:
      > >
      > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > > dropping ALL JS arguments that are currently located on the stack.
      > > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > > semantics of this instruction because in case of presence of declared
      > > stack parameters it's impossible to distinguish the following cases:
      > > 1) stack parameter is included in JS arguments (and therefore it will
      > >    be dropped as a part of 'pop' number of arguments),
      > > 2) stack parameter is NOT included in JS arguments (and therefore it
      > >    should be dropped in ADDITION to the 'pop' number of arguments).
      > >
      > > This issue wasn't noticed before because builtins with stack parameters
      > > relied on adapter frames machinery to ensure that the expected
      > > parameters are present on the stack, but on the same time the adapter
      > > frame tearing down code was effectively recovering the stack pointer
      > > potentially broken by the CSA builtin.
      > >
      > > Once we get rid of the arguments adapter frames keeping stack pointer
      > > in a valid state becomes crucial.
      > >
      > > Bug: v8:5269, v8:10201
      > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70454}
      >
      > Tbr: tebbi@chromium.org
      > Bug: v8:5269
      > Bug: v8:10201
      > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70483}
      
      Tbr: tebbi@chromium.org
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
      Bug: v8:5269
      Bug: v8:10201
      Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70492}
      d2ab873d
    • Clemens Backes's avatar
      Revert "Reland "[csa] Fix semantics of PopAndReturn"" · c40b2b7e
      Clemens Backes authored
      This reverts commit 3593ee83.
      
      Reason for revert: MSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34798
      
      Original change's description:
      > Reland "[csa] Fix semantics of PopAndReturn"
      >
      > This is a reland of 5e5eaf79
      >
      > This CL fixes the "function returns address of local variable" issue
      > which GCC was complaining about by using inline assembly instead of
      > address of a local for getting stack pointer approximation.
      >
      > Original change's description:
      > > [csa] Fix semantics of PopAndReturn
      > >
      > > This CL prohibits using PopAndReturn from the builtins that
      > > have calling convention with arguments on the stack.
      > >
      > > This CL also updates the PopAndReturn tests so that even off-by-one
      > > errors in the number of poped arguments are caught which was not the
      > > case before.
      > >
      > > Motivation:
      > >
      > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > > dropping ALL JS arguments that are currently located on the stack.
      > > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > > semantics of this instruction because in case of presence of declared
      > > stack parameters it's impossible to distinguish the following cases:
      > > 1) stack parameter is included in JS arguments (and therefore it will
      > >    be dropped as a part of 'pop' number of arguments),
      > > 2) stack parameter is NOT included in JS arguments (and therefore it
      > >    should be dropped in ADDITION to the 'pop' number of arguments).
      > >
      > > This issue wasn't noticed before because builtins with stack parameters
      > > relied on adapter frames machinery to ensure that the expected
      > > parameters are present on the stack, but on the same time the adapter
      > > frame tearing down code was effectively recovering the stack pointer
      > > potentially broken by the CSA builtin.
      > >
      > > Once we get rid of the arguments adapter frames keeping stack pointer
      > > in a valid state becomes crucial.
      > >
      > > Bug: v8:5269, v8:10201
      > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70454}
      >
      > Tbr: tebbi@chromium.org
      > Bug: v8:5269
      > Bug: v8:10201
      > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70483}
      
      TBR=tebbi@chromium.org,ishell@chromium.org,victorgomes@chromium.org
      
      Change-Id: Icbd71d744a519a58e49feb917109228631b9d9a3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5269
      Bug: v8:10201
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467846Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70485}
      c40b2b7e
    • Igor Sheludko's avatar
      Reland "[csa] Fix semantics of PopAndReturn" · 3593ee83
      Igor Sheludko authored
      This is a reland of 5e5eaf79
      
      This CL fixes the "function returns address of local variable" issue
      which GCC was complaining about by using inline assembly instead of
      address of a local for getting stack pointer approximation.
      
      Original change's description:
      > [csa] Fix semantics of PopAndReturn
      >
      > This CL prohibits using PopAndReturn from the builtins that
      > have calling convention with arguments on the stack.
      >
      > This CL also updates the PopAndReturn tests so that even off-by-one
      > errors in the number of poped arguments are caught which was not the
      > case before.
      >
      > Motivation:
      >
      > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > dropping ALL JS arguments that are currently located on the stack.
      > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > semantics of this instruction because in case of presence of declared
      > stack parameters it's impossible to distinguish the following cases:
      > 1) stack parameter is included in JS arguments (and therefore it will
      >    be dropped as a part of 'pop' number of arguments),
      > 2) stack parameter is NOT included in JS arguments (and therefore it
      >    should be dropped in ADDITION to the 'pop' number of arguments).
      >
      > This issue wasn't noticed before because builtins with stack parameters
      > relied on adapter frames machinery to ensure that the expected
      > parameters are present on the stack, but on the same time the adapter
      > frame tearing down code was effectively recovering the stack pointer
      > potentially broken by the CSA builtin.
      >
      > Once we get rid of the arguments adapter frames keeping stack pointer
      > in a valid state becomes crucial.
      >
      > Bug: v8:5269, v8:10201
      > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70454}
      
      Tbr: tebbi@chromium.org
      Bug: v8:5269
      Bug: v8:10201
      Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70483}
      3593ee83
  20. 12 Oct, 2020 2 commits
    • Zhi An Ng's avatar
      Revert "[csa] Fix semantics of PopAndReturn" · d813f56c
      Zhi An Ng authored
      This reverts commit 5e5eaf79.
      
      Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929?
      
      Original change's description:
      > [csa] Fix semantics of PopAndReturn
      >
      > This CL prohibits using PopAndReturn from the builtins that
      > have calling convention with arguments on the stack.
      >
      > This CL also updates the PopAndReturn tests so that even off-by-one
      > errors in the number of poped arguments are caught which was not the
      > case before.
      >
      > Motivation:
      >
      > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > dropping ALL JS arguments that are currently located on the stack.
      > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > semantics of this instruction because in case of presence of declared
      > stack parameters it's impossible to distinguish the following cases:
      > 1) stack parameter is included in JS arguments (and therefore it will
      >    be dropped as a part of 'pop' number of arguments),
      > 2) stack parameter is NOT included in JS arguments (and therefore it
      >    should be dropped in ADDITION to the 'pop' number of arguments).
      >
      > This issue wasn't noticed before because builtins with stack parameters
      > relied on adapter frames machinery to ensure that the expected
      > parameters are present on the stack, but on the same time the adapter
      > frame tearing down code was effectively recovering the stack pointer
      > potentially broken by the CSA builtin.
      >
      > Once we get rid of the arguments adapter frames keeping stack pointer
      > in a valid state becomes crucial.
      >
      > Bug: v8:5269, v8:10201
      > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70454}
      
      TBR=tebbi@chromium.org,ishell@chromium.org
      
      Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5269
      Bug: v8:10201
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70458}
      d813f56c
    • Igor Sheludko's avatar
      [csa] Fix semantics of PopAndReturn · 5e5eaf79
      Igor Sheludko authored
      This CL prohibits using PopAndReturn from the builtins that
      have calling convention with arguments on the stack.
      
      This CL also updates the PopAndReturn tests so that even off-by-one
      errors in the number of poped arguments are caught which was not the
      case before.
      
      Motivation:
      
      PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      dropping ALL JS arguments that are currently located on the stack.
      Disallowing PopAndReturn in builtins with stack arguments simplifies
      semantics of this instruction because in case of presence of declared
      stack parameters it's impossible to distinguish the following cases:
      1) stack parameter is included in JS arguments (and therefore it will
         be dropped as a part of 'pop' number of arguments),
      2) stack parameter is NOT included in JS arguments (and therefore it
         should be dropped in ADDITION to the 'pop' number of arguments).
      
      This issue wasn't noticed before because builtins with stack parameters
      relied on adapter frames machinery to ensure that the expected
      parameters are present on the stack, but on the same time the adapter
      frame tearing down code was effectively recovering the stack pointer
      potentially broken by the CSA builtin.
      
      Once we get rid of the arguments adapter frames keeping stack pointer
      in a valid state becomes crucial.
      
      Bug: v8:5269, v8:10201
      Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70454}
      5e5eaf79
  21. 09 Oct, 2020 1 commit
  22. 29 Sep, 2020 2 commits
  23. 28 Sep, 2020 1 commit
  24. 25 Sep, 2020 1 commit
  25. 14 Sep, 2020 1 commit
  26. 10 Sep, 2020 1 commit
  27. 08 Sep, 2020 1 commit
  28. 03 Sep, 2020 1 commit