1. 07 Apr, 2022 1 commit
  2. 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
  3. 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
  4. 27 Jan, 2022 1 commit
  5. 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
  6. 18 Jan, 2022 1 commit
  7. 09 Nov, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Clarify class annotations · 4dc59509
      Seth Brenith authored
      As Nico pointed out in [1], it is a little strange that the pair of
      annotations "@export @customCppClass" behaves similarly to the keyword
      "extern": both indicate that the class is defined in a C++ file and
      Torque generates only a base class template for it. In this change, I
      explore a possible alternative which might be more consistent.
      
      Removed annotations:
      - @customCppClass, which required @export, instructed Torque to only
        generate a base class template instead of a full class.
      - @customMap, which also required @export, instructed Torque to not emit
        code for setting up a unique Map instance for the class.
      
      Added annotations:
      - @generateUniqueMap, which requires extern, instructs Torque to emit
        code for setting up a unique Map instance for the class.
      - @generateFactoryFunction, which requires extern, instructs Torque to
        emit a function for creating a class instance.
      
      Subtracting two annotations and adding two others still leaves us with
      way too many annotations, but the usage of "extern" becomes more
      consistent and I think that the new opt-in annotations might be easier
      to understand.
      
      [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit
      
      Bug: v8:7793
      Change-Id: Ic9e147a095bc492d6645001b9275357386e8adcf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266008Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77799}
      4dc59509
  8. 05 Nov, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Get rid of `weak` keyword · 6745405f
      Seth Brenith authored
      Torque allows a `weak` keyword on class field declarations. This keyword
      is confusing, because it means two completely different things:
      
      1. This field should be included in the weak fields section, meaning the
         field's offset should be in the range [kStartOfWeakFieldsOffset,
         kEndOfWeakFieldsOffset).
      2. If a BodyDescriptor is generated for this class, then this field
         should be visited using *custom* weakness semantics
         (IterateCustomWeakPointers, not IterateMaybeObjectPointers).
      
      I propose the following updated behavior, which I think is a bit more
      reasonable:
      
      1. To request that the generated BodyDescriptor use custom weakness
         semantics, use a new annotation @customWeakMarking.
      2. The weak fields section includes all fields that can be a Weak<T>
         type, plus those annotated with @customWeakMarking.
      
      These new rules require reordering fields in two classes which didn't
      already have all of their strong fields adjacent.
      
      Bug: v8:7793
      Change-Id: Ic9d741986afa7fc1be3de044af5cae11a3c64d8c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3261968
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77739}
      6745405f
  9. 30 Sep, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Get rid of @noVerifier annotation" · 07d82db1
      Seth Brenith authored
      This is a reland of 94958172
      
      Original change's description:
      > [torque] Get rid of @noVerifier annotation
      >
      > As one small step toward reducing annotations, I propose that all
      > classes get generated verifiers unless they've opted out of C++ class
      > generation via @doNotGenerateCppClass, and that generated verifiers
      > always verify every Torque-defined field. If a generated verifier is
      > incorrect, such as for JSFunction or DataHandler, we can just avoid
      > calling it and hand-code the verification.
      >
      > Bug: v8:7793
      > Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#77145}
      
      Bug: v8:7793
      Change-Id: I3da34705bf9fc2b1886161f8f59c7275583f7fc4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194812
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77168}
      07d82db1
  10. 29 Sep, 2021 3 commits
    • Seth Brenith's avatar
      [torque] Get rid of @generatePrint annotation · 267b067b
      Seth Brenith authored
      I'm trying to remove annotations and make behavior more consistent. For
      @generatePrint, there are two options: either generate printers for
      every extern class, or never generate printers for extern classes. This
      change implements the option of always generating printers. Classes that
      require custom printing can easily hide the generated printer by using
      DECL_PRINTER. This causes the generated file
      gen/torque-generated/objects-printer.cc to grow to 1600 lines, including
      many functions that are never used, but I think the consistency benefit
      outweighs a little more compilation time on one file. This change also
      removes custom printers in cases where the generated printer includes
      all of the same content.
      
      If folks would prefer the option to never generate printers, I'm open to
      doing that instead. I like the notion that generating more code could
      reduce the friction of adding new classes and thereby encourage people
      to define precise types rather than using FixedArrays, but the current
      implementation of generated printers is limited, and many printers have
      been customized to show the data that matters the most. Unlike verifiers
      and body descriptors, there are no correctness or safety concerns with
      hand-written printers.
      
      Some bugs showed up once we start generating printers for everything,
      and this change fixes them:
      - Printers incorrectly included ungettable fields like padding
      - Printers called getters which might be hidden by hand-written classes
      - The generated getter for Map::instance_type used
        ReadField<InstanceType>, which is not an arithmetic type since it's an
        enum
      
      One more tiny drive-by fix: added a missing newline in the printers for
      JSMap and JSSet.
      
      Bug: v8:7793
      Change-Id: Ib9e9575fbcb57879935ff18bf4db49fe276d2966
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172190Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77152}
      267b067b
    • Maya Lekova's avatar
      Revert "[torque] Get rid of @noVerifier annotation" · 8679a4e1
      Maya Lekova authored
      This reverts commit 94958172.
      
      Reason for revert: Breaks arm/arm64 ports, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/30120/blamelist
      
      Original change's description:
      > [torque] Get rid of @noVerifier annotation
      >
      > As one small step toward reducing annotations, I propose that all
      > classes get generated verifiers unless they've opted out of C++ class
      > generation via @doNotGenerateCppClass, and that generated verifiers
      > always verify every Torque-defined field. If a generated verifier is
      > incorrect, such as for JSFunction or DataHandler, we can just avoid
      > calling it and hand-code the verification.
      >
      > Bug: v8:7793
      > Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#77145}
      
      Bug: v8:7793
      Change-Id: I56da8a9726d23470e927be1be5e7bcede1399861
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194262
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77146}
      8679a4e1
    • Seth Brenith's avatar
      [torque] Get rid of @noVerifier annotation · 94958172
      Seth Brenith authored
      As one small step toward reducing annotations, I propose that all
      classes get generated verifiers unless they've opted out of C++ class
      generation via @doNotGenerateCppClass, and that generated verifiers
      always verify every Torque-defined field. If a generated verifier is
      incorrect, such as for JSFunction or DataHandler, we can just avoid
      calling it and hand-code the verification.
      
      Bug: v8:7793
      Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77145}
      94958172
  11. 21 Jul, 2021 1 commit
  12. 10 May, 2021 1 commit
    • Nico Hartmann's avatar
      [Torque] Finalize torque-generated synchronized accessors · 8da583ee
      Nico Hartmann authored
      Torque-generated relaxed/acquire/release accessors now expect an
      additional Tag argument to be more consistent with handwritten
      accessors.
      
      Torque's annotations are renamed from @relaxedRead, @relaxedWrite,
      @acquireRead and @releaseWrite to @cppRelaxedLoad, @cppRelaxedStore,
      @cppAcquireLoad and @cppReleaseStore, repesectively. This renaming
      shall better reflect the fact that those annotations just generate
      corresponding synchronization on the generated C++ accessors
      (not CSA code) and be more consistent with the C++ side of things
      where "Load" and "Store" is used instead of "Read" and "Write".
      
      This CL uses these new annotations on a few fields in DebugInfo and
      FunctionTemplateInfo to have Torque generate accessors automatically.
      
      Bug: v8:11122
      Change-Id: Ibdf3e6b37a254605ff69ba9a50d7b1646790ea15
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876857Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74463}
      8da583ee
  13. 15 Mar, 2021 1 commit
  14. 23 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add LazyNode support · ede27407
      Seth Brenith authored
      This change adds a new abstract type Lazy<T> which can be used to
      interoperate with CSA code that uses LazyNode. This new type has special
      code-generation rules because its generated type is not TNode<...> but
      std::function<TNode<...>()>. Torque code can do nothing with this type
      except pass it around, but passing it to the CSA function RunLazy is an
      easy way to execute the std::function and get back a normal value.
      Torque code can also create Lazy<T> values using the intrinsic function
      %MakeLazy, which takes the name of a macro as its first parameter,
      followed by arguments to that macro which will be passed when the
      LazyNode is evaluated. We use the macro's name because the language
      doesn't support taking references to macros, and implementing such a
      feature would be complicated.
      
      Bug: v8:7793
      Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72964}
      ede27407
  15. 09 Feb, 2021 1 commit
  16. 03 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add @relaxedRead annotation · cffd8bc8
      Seth Brenith authored
      When generating getters, Torque needs to decide whether to perform a
      normal or relaxed load. Thus far, it has used the somewhat non-obvious
      logic that any indexed field with tagged non-smi data gets relaxed
      loads. This change adds a new annotation @relaxedRead to be consistent
      with the existing @relaxedWrite annotation. I added @relaxedRead
      annotations on any field that previously had this automatic behavior and
      whose getter is called, except for those in ScopeInfo because I'm
      relatively confident that it doesn't need relaxed access.
      
      Bug: v8:7793
      Change-Id: I9987eea13760b967f1b8a3189b69742e55140c30
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2600113
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72499}
      cffd8bc8
  17. 30 Nov, 2020 1 commit
  18. 19 Nov, 2020 1 commit
  19. 11 Nov, 2020 1 commit
  20. 10 Nov, 2020 1 commit
  21. 09 Nov, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] allow exported classes with custom C++ class" · bd75b0ba
      Tobias Tebbi authored
      This is a reland of 26f10ecd
      
      Change compared to original CL:
      The deserializer changes StrongDescriptorArray to DescriptorArray.
      Since this CL uses separate BodyDescriptors for the two kinds of
      descriptor arrays, this caused a DCHECK failure when the deserializer
      changes the map while the object is visited from the concurrent marking
      thread. Fix this by disabling the corresponding checks.
      
      
      Original change's description:
      > [torque] allow exported classes with custom C++ class
      >
      > Introduce a new annotation @customCppClass that can be used for
      > non-extern @export classes, that is, generate everything, remove
      > boilerplate from all the internal lists and switches, but allow
      > a custom C++ class, which in turn also allows overwriting the generated
      > print and verify functions.
      >
      > Port DescriptorArray and StrongDescriptorArray as an example.
      >
      > Bug: v8:7793
      > Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70989}
      
      Bug: v8:7793
      Change-Id: I7505fb111896991d16d7d113704c8c3676669f34
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526383Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71048}
      bd75b0ba
  22. 05 Nov, 2020 2 commits
  23. 22 Oct, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Strict verification of abstract types · 50d474a2
      Seth Brenith authored
      Originally, the Torque-generated verifier for a field with type
      Undefined|Zero|NonNullForeign would check `f.IsUndefined() || f.IsZero()
      || f.IsNonNullForeign()`. At some point, we changed Torque so that it
      now generates the much weaker `f.IsOddball() || f.IsSmi() ||
      f.IsForeign()`. This change returns the verifiers to their initial
      precision. Mostly we can use the names of abstract types to build up the
      correct type check expression, but a few abstract types like
      PodArrayOfWasmValueType have no way that we can tell them apart from
      their parent type at runtime. It would be confusing to have a function
      Object::IsPodArrayOfWasmValueType which actually just checks whether the
      object is a ByteArray, so this change introduces a new annotation which
      allows abstract type declarations to state that they should use their
      parent type during verification.
      
      This change also adds new test cases to help avoid future regressions of
      this logic.
      
      Bug: v8:7793
      Change-Id: Ie5046d742fd45e0e0f6c2ba387d909e9f2ac6df1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469960Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70698}
      50d474a2
  24. 27 Jul, 2020 1 commit
  25. 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
  26. 30 May, 2020 1 commit
  27. 04 May, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] improve GC visitors · f1400e43
      Tobias Tebbi authored
      Summary of changes:
      
      - GC visitors no longer rely on superclass visitors, but instead visit
        everything themselves. This enables generating better code.
      - Try to match simple body descriptors to reduce the amount of generated
        code.
      - Turn SizeFor(instance) into an AllocatedSize() method.
      - Remove the special handling of resizable object sizes from Torque
        and instead overwrite AllocatedSize in classes that need special
        handling in C++.
      - Split the visitor id lists depending on whether the class has pointer
        fields.
      - Turn Torque-generated body descriptors into an .inc file to
        simplify includes.
      - Fix generated size functions to properly align the size.
      - Generate GC visitors (and C++ class definitions) for all string
        classes and FixedArray, WeakFixedArray, and WeakArrayList.
      - Store generated instance types in Torque class types. This is only
        used to determine if a type has a single instance type in this CL.
      
      Bug: v8:7793
      Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67542}
      f1400e43
  28. 29 Apr, 2020 1 commit
  29. 18 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] add const references and disallow const class field writes · d7e02ea4
      Tobias Tebbi authored
      - Allow type expression for abstract type supertypes.
        For consistency, and ease of implementation, also allow this for enums.
      - Allow subtyping of structs. This requires changing all places where we
        checked for struct types and instead check if we have a subtype of a
        struct type.
      - This allows defining two subtypes of the Reference<T> struct for
        mutable and constant references. Mutable references are a subtype of
        constant references.
      - &T desugars to MutableReference<T>
        const &T desugars to ConstReference<T>
      - A const field of a class produces a constant reference.
        A const field of a mutable reference to a struct is const.
        A mutable field of a const reference to a struct is const.
      - It is possible to assign a new struct value to a mutable reference to
        a struct, even if the struct contains const fields. This is analogous
        to allowing assignments of let-bound structs with constant fields.
      
      Not in this CL:
      - A notion of const slices.
      - Applying const to appropriate class fields.
      
      Bug: v8:7793
      Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66759}
      d7e02ea4
  30. 09 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored
      In the process:
      
      * Augment C++-generated Torque classes with SizeFor methods to
        calculate size of instances.
      
      * Add a new "@generateBodyDescriptor" annotation that causes Torque to
        generate C++ BodyDescriptors code that can be used to visit objects
        compatible with existing V8 mechanisms, e.g. GC
      
      * Fully automate C++ macro machinery so that adding non-extern Torque
        class doesn't require any C++ changes, including ensuring generation
        of instance types and proper boilerplate for validators and
        printers.
      
      * Make handling of @export a true annotation, allowing the modifier to
        be used on class declarations.
      
      * Add functionality such that classes with the @export annotation are
        available to be used from C++. Field accessors for exported classes
        are public and factory methods are generated to create instances of
        the objects from C++.
      
      * Change the Torque compiler such that Non-exported classes implicitly
        have the @generateBodyDescriptor annotation added and causes both
        verifiers and printers to be generated.
      
      * Switch non-extern Torque classes from using existing Struct-based
        machinery to being first-class classes that support more existing
        Torque class features.
      
      Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  31. 26 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Support bitfield structs stored within Smis" · 527f9de1
      Seth Brenith authored
      This reverts commit 4dc1fb4e.
      
      Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
      
      Original change's description:
      > Revert "[torque] Support bitfield structs stored within Smis"
      >
      > This reverts commit e5e4ea96.
      >
      > Reason for revert: mysterious performance regression chromium:1052756
      >
      > Original change's description:
      > > [torque] Support bitfield structs stored within Smis
      > >
      > > This change moves the definition of the bits stored in DebugInfo::flags
      > > to Torque, and updates the only Torque usage of that field to use more
      > > natural syntax. This is intended as an example of common patterns found
      > > in various other classes. Several supporting changes are required:
      > >
      > > 1. Add a new type representing a bitfield struct stored within a Smi. It
      > >    is currently called SmiTagged, but I'm open to suggestions.
      > > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      > >    occupy only one bit each.
      > > 3. Add a new case to MachineOperatorReducer that makes the generated
      > >    code for IncBlockCounter match with what was generated before this
      > >    change.
      > > 4. Add support for reporting these bitfields in the postmortem debugging
      > >    API. The format matches existing bitfields but with an offset value
      > >    that includes the SMI shift size.
      > >
      > > Bug: v8:7793
      > > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66182}
      >
      > Bug: chromium:1052756, v8:7793
      > Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66349}
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66465}
      527f9de1
  32. 19 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque] Support bitfield structs stored within Smis" · 4dc1fb4e
      Seth Brenith authored
      This reverts commit e5e4ea96.
      
      Reason for revert: mysterious performance regression chromium:1052756
      
      Original change's description:
      > [torque] Support bitfield structs stored within Smis
      >
      > This change moves the definition of the bits stored in DebugInfo::flags
      > to Torque, and updates the only Torque usage of that field to use more
      > natural syntax. This is intended as an example of common patterns found
      > in various other classes. Several supporting changes are required:
      >
      > 1. Add a new type representing a bitfield struct stored within a Smi. It
      >    is currently called SmiTagged, but I'm open to suggestions.
      > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      >    occupy only one bit each.
      > 3. Add a new case to MachineOperatorReducer that makes the generated
      >    code for IncBlockCounter match with what was generated before this
      >    change.
      > 4. Add support for reporting these bitfields in the postmortem debugging
      >    API. The format matches existing bitfields but with an offset value
      >    that includes the SMI shift size.
      >
      > Bug: v8:7793
      > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66182}
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66349}
      4dc1fb4e
  33. 07 Feb, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Support bitfield structs stored within Smis · e5e4ea96
      Seth Brenith authored
      This change moves the definition of the bits stored in DebugInfo::flags
      to Torque, and updates the only Torque usage of that field to use more
      natural syntax. This is intended as an example of common patterns found
      in various other classes. Several supporting changes are required:
      
      1. Add a new type representing a bitfield struct stored within a Smi. It
         is currently called SmiTagged, but I'm open to suggestions.
      2. Add an enum-style output for Torque bitfield structs whose bitfields
         occupy only one bit each.
      3. Add a new case to MachineOperatorReducer that makes the generated
         code for IncBlockCounter match with what was generated before this
         change.
      4. Add support for reporting these bitfields in the postmortem debugging
         API. The format matches existing bitfields but with an offset value
         that includes the SMI shift size.
      
      Bug: v8:7793
      Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66182}
      e5e4ea96
  34. 16 Jan, 2020 1 commit
  35. 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
  36. 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
  37. 21 Nov, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] shape: define in-object properties properly · cfab6505
      Tobias Tebbi authored
      This introduces a new keyword "shape" in addition to "class",
      which allows the definition of a type that extends a JSObject
      subclass and specifies one or several maps with statically
      known in-object properties.
      Differences compared to normal classes:
      - Shapes are transient since they specify maps instead of
        instance types.
      - Shapes have a known size.
      - Fields of shapes are always in-object properties. In particular,
        this means that their offset is after kHeaderSize.
      - It's forbidden to inherited from shapes.
      - Since shapes usually specify NativeContext-dependent maps, it's
        not possible to write runtime type-checks for them. Thus this CL
        avoids mapping them to their own TNode type, as the CAST macro
        won't work properly. We had runtime-checks for some of them
        nevertheless, some of them scarily confusing like
        IsJSSloppyArgumentsObject, that actually just checked the instance
        type.
      
      Drive-by cleanups and simplifications:
      - Allow subclassing from non-abstract classes and remove
        @dirtyInstantiatedAbstractClass. This attribute stems from a mis-
        conception of how instance types work, and with this change it
        ceases to have semantic influence.
      - Replace the existing JSArgumentsObject subclasses into two shapes.
        JSArgumentsObjectWithLength had to be removed since shapes don't
        support subclassing.
      - Place kHeaderSize correctly for objects with indexed fields.
      
      Design doc:
      https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU
      
      Bug: v8:8944
      
      Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65108}
      cfab6505