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. 18 Mar, 2020 1 commit
  3. 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
  4. 23 May, 2019 1 commit
  5. 09 Jan, 2019 1 commit
  6. 20 Dec, 2018 1 commit
  7. 18 Dec, 2018 1 commit
  8. 14 Dec, 2018 1 commit
  9. 08 Dec, 2018 1 commit
  10. 25 Nov, 2018 1 commit
  11. 23 Nov, 2018 4 commits
  12. 11 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce dedicated JSAsyncFunctionObject. · a63987a4
      Benedikt Meurer authored
      This JSAsyncFunctionObject represents the implicit generator object
      inside of async functions, and also holds the outer promise for the
      async functions. This in turn allows us to get rid of the .promise
      in the Parser / BytecodeGenerator completely, and will make it
      possible to build zero-cost async stack traces independent of the
      concrete synchronous part of the stack frame (which currently breaks
      in Node.js).
      
      In the bytecode all the async function operations now take this new
      JSAsyncFunctionObject instead of passing both the .generator_object
      and the .promise, which further simplifies and shrinks the bytecode.
      It also reduces the size of async function frames, potentially making
      the suspend/resume cheaper.
      
      This also changes `await` to use intrinsics instead of calling to
      special JSFunctions on the native context, and thus reduces the size of
      the native contexts.
      
      Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
      to TurboFan.
      
      Bug: v8:7253, v8:7522
      Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
      Ref: nodejs/node#11865
      Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
      Reviewed-on: https://chromium-review.googlesource.com/c/1273049
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56554}
      a63987a4
  13. 25 Jul, 2018 1 commit
  14. 20 Jul, 2018 1 commit