• Seth Brenith's avatar
    [torque] move more bitfield definitions to Torque · 87c16da5
    Seth Brenith authored
    This change moves the definitions of the bitfield flags used by Symbol
    and Map to Torque. Symbol could directly follow the pattern established
    by SharedFunctionInfo, but Map required some other changes:
    - Until now, Torque bitfield definitions have required unsigned types. I
      thought that this would be the least-surprising behavior, since we
      never sign-extend when decoding bitfield values. However, I believe
      that the amount of churn involved in making ElementsKind be unsigned
      outweighs the benefit we were getting from this restriction (and
      similar difficulties are likely to arise in converting other bitfield
      structs to Torque), so this CL updates Torque to allow signed bitfield
      values.
    - If we try to make Map extend from all of the generated classes that
      define its flags, we end up with class sizing problems because some
      compilers only apply empty base class optimization to the first in a
      row of empty base classes. We could work around this issue by
      generating macros instead of classes, but I took this as an
      opportunity for a minor clean-up instead: rather than having bitfield
      definitions for several different bitfield structs all jumbled
      together in Map, they can be split up. I think this makes the code a
      little easier to follow, but if others disagree I'm happy to implement
      macro generation instead.
    
    Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
    Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
    Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
    Cr-Commit-Position: refs/heads/master@{#65701}
    87c16da5
macro-assembler-ppc.cc 95.5 KB