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. 13 Oct, 2020 1 commit
  4. 05 Oct, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Add C++ backend for Torque compiler · c7c5d50d
      Seth Brenith authored
      This change adds a new code generator, which supports a subset of the
      instructions supported by the existing CSAGenerator, and instead of
      generating CSA it generates runtime C++ code. The new generator is used
      to generate a set of Torque macros that return slices to indexed fields.
      These new macros should be sufficient to eventually support
      Torque-generated field accessors, BodyDescriptors, verifier functions,
      and postmortem field inspection in debug_helper.
      
      Bug: v8:7793
      Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70313}
      c7c5d50d