• 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
Name
Last commit
Last update
..
arm Loading commit data...
arm64 Loading commit data...
ia32 Loading commit data...
mips Loading commit data...
mips64 Loading commit data...
ppc Loading commit data...
s390 Loading commit data...
x64 Loading commit data...
DEPS Loading commit data...
OWNERS Loading commit data...
basic-block-profiler.cc Loading commit data...
basic-block-profiler.h Loading commit data...
code-tracer.h Loading commit data...
compilation-statistics.cc Loading commit data...
compilation-statistics.h Loading commit data...
disasm.h Loading commit data...
disassembler.cc Loading commit data...
disassembler.h Loading commit data...
eh-frame.cc Loading commit data...
eh-frame.h Loading commit data...
gdb-jit.cc Loading commit data...
gdb-jit.h Loading commit data...
objects-debug.cc Loading commit data...
objects-printer.cc Loading commit data...
perf-jit.cc Loading commit data...
perf-jit.h Loading commit data...
unwinder.cc Loading commit data...
unwinder.h Loading commit data...
unwinding-info-win64.cc Loading commit data...
unwinding-info-win64.h Loading commit data...