1. 04 Feb, 2022 1 commit
    • Nico Hartmann's avatar
      Reland "Reland "[Torque] Generalize Torque literals to larger size"" · 362b30eb
      Nico Hartmann authored
      This is a reland of 517ed4ad
      
      Original change's description:
      > Reland "[Torque] Generalize Torque literals to larger size"
      >
      > Previously, literals in Torque were stored as double values, which
      > made it impossible to precisely represent 64 bit integer values.
      > This CL replaces the old literal expression with an integer and
      > floating point literal expression that are unbounded in size. We
      > allow implicit conversion of these literals to arbitary integer
      > and floating point types respectively and insert a corresponding
      > bounds check into generated CSA.
      >
      > Changes in the reland: Simplified IntegerLiteral to single digit.
      >
      > Bug: v8:7793, chromium:1289282
      > Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78811}
      
      Bug: v8:7793, chromium:1289282
      Change-Id: I7aadc4d2c9494f03eae85e94949c8f4cab7a075c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3437047Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78939}
      362b30eb
  2. 28 Jan, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "Reland "[Torque] Generalize Torque literals to larger size"" · d96934c7
      Nico Hartmann authored
      This reverts commit 517ed4ad.
      
      Reason for revert: There still seems to be an issue on V8 Win msvc related to this CL (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/20568/overview).
      
      Original change's description:
      > Reland "[Torque] Generalize Torque literals to larger size"
      >
      > Previously, literals in Torque were stored as double values, which
      > made it impossible to precisely represent 64 bit integer values.
      > This CL replaces the old literal expression with an integer and
      > floating point literal expression that are unbounded in size. We
      > allow implicit conversion of these literals to arbitary integer
      > and floating point types respectively and insert a corresponding
      > bounds check into generated CSA.
      >
      > Changes in the reland: Simplified IntegerLiteral to single digit.
      >
      > Bug: v8:7793, chromium:1289282
      > Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78811}
      
      Bug: v8:7793, chromium:1289282
      Change-Id: I818cec9625fbd827a4a30088d8c8b759fb6c50d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3424484
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78847}
      d96934c7
  3. 27 Jan, 2022 1 commit
  4. 20 Jan, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "[Torque] Generalize Torque literals to larger size" · 362e265d
      Nico Hartmann authored
      This reverts commit 757830b0.
      
      Reason for revert: Speculatively revert due to a number of
      performance regressions
      
      Original change's description:
      > [Torque] Generalize Torque literals to larger size
      >
      > Previously, literals in Torque were stored as double values, which
      > made it impossible to precisely represent 64 bit integer values.
      > This CL replaces the old literal expression with an integer and
      > floating point literal expression that are unbounded in size. We
      > allow implicit conversion of these literals to arbitary integer
      > and floating point types respectively and insert a corresponding
      > bounds check into generated CSA.
      >
      > Bug: v8:7793
      > Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78671}
      
      Bug: v8:7793
      Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78706}
      362e265d
  5. 18 Jan, 2022 1 commit
  6. 17 Nov, 2021 1 commit
    • Tobias Tebbi's avatar
      [builtins] add Torque fast-path for String.prototype.localeCompare · 6181ce59
      Tobias Tebbi authored
      This fast path works for ASCII-only strings and is similar to the
      existing fast-path in C++. Important differences:
      - The locale check is done at Turbofan optimization time instead of
        at runtime
      - Use tables of size 256 instead of 128 to save a bounds-check when
        handling one-byte strings.
      - It first performs an equality check that's optimized for detecting
        inequality quickly by comparing the strings from both ends. If the
        equality check succeeds, we are done. Otherwise chances are high
        that the strings differ according to collation level L1 already.
        Therefore, we first do an L1 check and perform the L3 check
        only when L1 didn't find a difference. This is based on the assumption
        that few strings are identical except for different capitalization.
      - Use the Torque version of string flattening instead of the runtime
        version.
      
      Bug: v8:12196
      Change-Id: I2d043c1138846783f6d567b736d34063ba9301e5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268465Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77946}
      6181ce59
  7. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored
      This is a reland of 45227ffd
      Differences:
      - Handle one more flags conflict in variants.py.
      - Disallow %VerifyType without --concurrent-recompilation.
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
      Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  8. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored
      This reverts commit 45227ffd.
      
      Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#77566}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored
      Extend type assertions to all types covering JavaScript values.
      This is achieved by allocating type representations on the heap using
      newly defined HeapObject subclasses. To allocate these in the compiler,
      we disable concurrent compilation for the --assert-types flag for now.
      
      Fix two type errors that came up with the existing tests:
      1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
         OtherObject.
      2. OperationTyper::NumberToString(Type) can type the result as the
         HeapConstant Factory::zero_string(). However, NumberToString does
         not always produce this string. To avoid regressions, the CL keeps
         the HeapConstant type and changes the runtime and builtin code to
         always produce the canonical "0" string.
      
      A few tests were failing because they check for truncations to work
      and prevent deoptimization. However, AssertType nodes destroy all
      truncations (which is by design), so these tests are incompatible
      and now disabled for the assert_types variant.
      
      Drive-by fix: a few minor Torque issues that came up.
      
      Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  9. 30 Sep, 2021 1 commit
  10. 02 Sep, 2021 1 commit
  11. 31 Mar, 2021 1 commit
    • Igor Sheludko's avatar
      Reland "[dict-proto] SIMD support for SwissNameDictionary in Torque" · 4cd6ad9e
      Igor Sheludko authored
      This is a reland of 856e8577
      The diff compared to the first attempt is that the tests that
      require SSSE3/AVX are not run when these CPU features are not
      available.
      
      Original change's description:
      > [dict-proto] SIMD support for SwissNameDictionary in Torque
      >
      > This CL adds a Torque-counterpart for swiss_table::GroupSse2Impl in
      > Torque. This allows the Torque version of SwissNameDictionary to use
      > SSE for lookups, rather than needing to bailout to the runtime on
      > x64/ia32.
      >
      > Bug: v8:11330
      > Change-Id: I74e3f97c460a8b89031016967ec0e545265016a9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2787485
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Zhi An Ng <zhin@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73727}
      
      Bug: v8:11330
      Cq-Include-Trybots: luci.v8.try:v8_linux_optional_rel_ng
      Change-Id: Ibfa5ae5a39333778ea0d0406d5ea4ad683ad0dbe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794431Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73740}
      4cd6ad9e
  12. 30 Mar, 2021 2 commits
  13. 22 Mar, 2021 1 commit
  14. 15 Mar, 2021 1 commit
  15. 05 Mar, 2021 1 commit
  16. 08 Dec, 2020 1 commit
  17. 04 Dec, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] uniform flattening and string access in Torque · 65d2c4b4
      Tobias Tebbi authored
      Port String::Flatten to Torque (using a fast C call for the
      non-allocating part) and provide fast and easy access to sequential
      string data in Torque: GetStringData() flattens if necessary and
      computes slices that allow direct access.
      
      Applications: String.prototype.replaceAll, String.prototype.endsWith,
        and String.prototype.beginsWith now use GetStringData() and direct
        slice access instead of the slow StringCharCodeAt and they no
        longer bail out to the runtime for flattening.
      
      Drive-by changes:
        - Expose String instance type bits as bitfields and enums in Torque.
        - Fix method lookup in Torque to include superclass methods.
        - Use char8 and char16 types in more places.
        - Allow fast C calls with void return type.
        - Add Torque macros to create subslices.
        - Add no-GC scopes to runtime functions loading external string data.
      
      
      Bug: v8:7793
      Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71611}
      65d2c4b4
  18. 05 Nov, 2020 1 commit
  19. 18 Aug, 2020 1 commit
  20. 06 Aug, 2020 1 commit
  21. 05 Aug, 2020 1 commit
  22. 27 Jul, 2020 1 commit
  23. 23 Jun, 2020 1 commit
    • Daniel Clifford's avatar
      [torque] generate Cast<> macros from Torque-defined classes · 1052dfb3
      Daniel Clifford authored
      This change enables automatic generation of Cast<> operators for
      classes that are defined in Torque.
      
      * Cast<> macros are generated for all classes that are defined in
        Torque code that are neither shapes nor marked with a new
        @doNotGenerateCast annotation.
      
      * Implicitly generated Cast macros simply call through to an
        internally-defined "DownCastForTorqueClass" macro that implements
        the cast using one of three strategies for efficiency. If the class
        has subclasses (i.e. a range of instance types including subtypes),
        the DownCastForTorqueClass checks for inclusion in the instance type
        range. If the class has a single instance type (i.e. no subclasses),
        then either 1) a map check is used if the class has a globally-
        defined map constant or 2) an equality check for the instance type
        is used.
      
      * Added new intrinsics to introspect class information, e.g. fetching
        instance type ranges for a class, accessing the globally-defined map
        for a class.
      
      * Removed a whole pile of existing explicit Cast<> operators that are
        no longer needed because of the implicitly generated Cast<> macros.
      
      * Added tests for the new Cast<> implementations.
      
      Bug: v8:7793
      Change-Id: I3aadb0c62b720e9de4e7978b9ec4f05075771b8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250239
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68478}
      1052dfb3
  24. 28 May, 2020 1 commit
  25. 20 May, 2020 1 commit
  26. 19 May, 2020 3 commits
  27. 04 May, 2020 1 commit
  28. 23 Apr, 2020 1 commit
  29. 04 Mar, 2020 1 commit
  30. 16 Jan, 2020 2 commits
  31. 27 Dec, 2019 1 commit
    • Daniel Clifford's avatar
      Port bitfield ScopeFlags to Torque · 7e8a197c
      Daniel Clifford authored
      In the process:
      
      * Rework the Torque definition of ScopeInfo to enable direct
        field-style access of ScopeFlags, removing some dead code in
        the process.
      * Allow implicit FromConstexpr conversion from subtypes of
        'constexpr A' to other types. This makes it possible/easy to
        convert constexpr versions of enums to other types, since the
        constexpr version of the enum isn't addressable. It's namespace
        isn't a valid namespace and is an implementation detail anyway.
      * Cleanup LanguageMode: Language mode is now an enum and directly
        mirrors the C++-side definition rather than being a Smi. With
        the changes above, a new type LanguageModeSmi is introduced
        that is the Smi representation of LanguageMode that can be
        implicitly casted from constexpr LanguageMode values.
      
      Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65561}
      7e8a197c
  32. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] multiple arrays in one object · 59e8d45a
      Tobias Tebbi authored
      This allows the definition of classes with several arrays and ports
      SmallOrderedHashTable subclasses to Torque as an example, including
      the existing CSA allocation functions for them.
      
      Overview of changes:
      - Introduce ResidueClass to encapsulate the modulo-arithmetic
        necessary to do alignment checks.
      - Add MachineOperatorReducer to the CSA pipeline to address now
        missing CSA ad-hoc constant folding that got blocked by a
        temporary phi.
      - Allow assignments to references to structs. This is needed to
        initialize the data_table part of SmallOrderedHashMap.
      - Make the NumberLiteralExpression AST-node store a double instead
        of a string. This is necessary to detect arrays with constant size
        used for padding.
      - Turn offsets into base::Optional<size_t> to ensure we don't use
        an invalid or statically unknown offset.
      - Remove CreateFieldReferenceInstruction since it doesn't work for
        complex offset computations and the logic can be expressed better
        in ImplementationVisitor.
      - Validate alignment of structs embedded in classes.
      
      Bug: v8:10004 v8:7793
      Change-Id: Ifa414b42278e572a0c577bf9da3d37f80771a258
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958011
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65538}
      59e8d45a
  33. 19 Dec, 2019 1 commit
  34. 18 Dec, 2019 1 commit
    • Nico Hartmann's avatar
      [torque] Enum language feature · fdc9fade
      Nico Hartmann authored
      This CL implements enums in Torque in three steps:
      
      1.) It implements necessary changes to Torque's type system. In
      particular, the constraints on constexpr types are relaxed such that
      constexpr types can exist without a corresponding non-constexpr
      version. Furthermore, constexpr and their non-constexpr counterpart
      need not be of the same kind of type. This allows an AbstractType to
      have a UnionType as its non-constexpr counterpart.
      
      2.) The enum feature itself is realized as a pure desugaring in the
      parser, where all required types, constants and macro specializations
      (like FromConstexpr<>) are generated from a simple enum declaration,
      such that enum entries are not just constants, but are namespace
      scoped and have distinct types so that they can be used within
      typeswitch constructs.
      
      3.) Almost all of the existing constants defined in torque
      (.tq files) are ported to new enum definitions.
      
      Bug: v8:10053
      Change-Id: I72426d3b1434f301fd690847e15603de0dc1021b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964392
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65503}
      fdc9fade
  35. 10 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] allow allocation of strings · 8ed9be48
      Tobias Tebbi authored
      This CL generalizes and improves how we handle allocations in Torque.
      
      Overview of the changes:
      - Remove obsolete special handling for JSObject classes, since it was
        incomplete: It breaks as soon as slack tracking is active.
      - Handle array initialization using slices.
      - Properly align allocation sizes. This enabled allocating strings.
      - Port AllocateSeq{One,Two}ByteString to Torque, which is much easier
        now than the old CSA code since allocation size alignment and
        large-object space allocation just happen out-of-the-box.
      - Remove obsolete or unnecessary intrinsics, some of them turn into
        macros in the torque_internal namespace.
      - Distinguish between header size and overall size for ClassType,
        make size optional and only defined when it is statically known.
      
      
      Bug: v8:10004 v8:7793
      Change-Id: I623db233e7fb4deed54e8039ae0c24705e9a44e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932356Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65397}
      8ed9be48