• 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
bytecode-array-builder-unittest.cc 31 KB