1. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  2. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  3. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  4. 22 Apr, 2020 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Allow storing to bitfield structs that are stored in Smis" · a9270e2b
      Seth Brenith authored
      This is a reland of 80843eda
      
      Original change's description:
      > [torque] Allow storing to bitfield structs that are stored in Smis
      > 
      > This change:
      > 1. Updates the Torque compiler to allow direct access to bitfields that
      >    are packed within Smi values, which previously would have required a
      >    separate untagging step,
      > 2. Updates JSRegExpStringIterator to represent its flags in Torque,
      > 3. Adds reduction cases in MachineOperatorReducer for when the input to
      >    a branch or the left-hand side of a Word32Equals is based on a 64-bit
      >    shift-and-mask operation which has been truncated to 32 bits, as is
      >    the case in the code generated by step 1, and
      > 4. Adds a reduction case in MachineOperatorReducer to remove an extra
      >    Word64And operation added by step 1.
      > 
      > Bug: v8:7793
      > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67290}
      
      Bug: v8:7793
      Change-Id: I783b6ec080042fec0e922927f6675dede458a072
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67305}
      a9270e2b
  5. 21 Apr, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] Allow storing to bitfield structs that are stored in Smis" · db61168a
      Francis McCabe authored
      This reverts commit 80843eda.
      
      Reason for revert: Causes compilation failure on macs
      
      https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
      
      
      Original change's description:
      > [torque] Allow storing to bitfield structs that are stored in Smis
      > 
      > This change:
      > 1. Updates the Torque compiler to allow direct access to bitfields that
      >    are packed within Smi values, which previously would have required a
      >    separate untagging step,
      > 2. Updates JSRegExpStringIterator to represent its flags in Torque,
      > 3. Adds reduction cases in MachineOperatorReducer for when the input to
      >    a branch or the left-hand side of a Word32Equals is based on a 64-bit
      >    shift-and-mask operation which has been truncated to 32 bits, as is
      >    the case in the code generated by step 1, and
      > 4. Adds a reduction case in MachineOperatorReducer to remove an extra
      >    Word64And operation added by step 1.
      > 
      > Bug: v8:7793
      > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67290}
      
      TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
      
      Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67291}
      db61168a
    • Seth Brenith's avatar
      [torque] Allow storing to bitfield structs that are stored in Smis · 80843eda
      Seth Brenith authored
      This change:
      1. Updates the Torque compiler to allow direct access to bitfields that
         are packed within Smi values, which previously would have required a
         separate untagging step,
      2. Updates JSRegExpStringIterator to represent its flags in Torque,
      3. Adds reduction cases in MachineOperatorReducer for when the input to
         a branch or the left-hand side of a Word32Equals is based on a 64-bit
         shift-and-mask operation which has been truncated to 32 bits, as is
         the case in the code generated by step 1, and
      4. Adds a reduction case in MachineOperatorReducer to remove an extra
         Word64And operation added by step 1.
      
      Bug: v8:7793
      Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67290}
      80843eda
  6. 18 Mar, 2020 1 commit
  7. 29 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [cleanup][torque] Use @generateCppClass in some simple cases, part 2 · a5811358
      Seth Brenith authored
      This patch is mostly mechanical. A few changes in
      implementation-visitor.cc might be worth mentioning:
      - Don't generate both field offset macros and class definitions for the
        same class. This was mostly just to keep me from forgetting to remove
        the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but
        also helpfully flagged that FixedArrayBase wasn't using the generated
        class that it requested.
      - Generate forward declarations for all tq-defined classes in
        internal-class-definitions-tq.h. This is helpful for making things
        compile when classes have fields of other class types.
      - When generating accessors for union types, use the nearest class type
        that contains the entire union rather than plain Object. This is
        important for compile-time type safety. It also required a few minor
        fixes elsewhere (isolate.cc, modules.cc, scope-info.cc,
        source-text-module.cc, and a correction of the field types in
        CallHandlerInfo to match how they're set in api.cc).
      
      Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63458}
      a5811358
  8. 06 Mar, 2019 1 commit
  9. 09 Jan, 2019 1 commit
  10. 08 Dec, 2018 1 commit
  11. 27 Nov, 2018 1 commit
  12. 22 Nov, 2018 1 commit
  13. 21 Sep, 2018 1 commit
  14. 12 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [cleanup] Remove Isolate parameter from object print · 13b899a5
      Leszek Swirski authored
      With ReadOnlyRoots and GetIsolate on JSReceiver, we can remove almost
      every isolate parameter from <Object>::Print. The remaining ones, like
      Map, are special-caseable for read-only maps, and as a result we can
      remove isolate parameters from <Object>::Print entirely.
      
      This patch also opportunistically cleans up a few places where isolates
      were only needed for Object::Print, such as TransitionAccessors and
      DescriptorArrays.
      
      TBR=yangguo@chromium.org,mstarzinger@chromium.org
      
      Bug: v8:7786
      Change-Id: Id44bd53b9893e679eea5f37b9548257595a1bfd9
      Reviewed-on: https://chromium-review.googlesource.com/1133385Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54401}
      13b899a5
  15. 26 Jun, 2018 1 commit
  16. 05 Apr, 2018 1 commit