- 07 Apr, 2022 1 commit
-
-
Nico Hartmann authored
This CL adds the requirements to port object definitions back to C++. A @cppObjectDefinition is introduced to annotate classes for which Torque shall merely generate asserts to check that offsets match between Torque and C++. As a first object, this CL ports Oddball back to C++. Bug: v8:12710 Change-Id: I1304d8980f6318ffccbc2ef7284cb9d46ff579e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3523046Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#79856}
-
- 04 Feb, 2022 1 commit
-
-
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: 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@{#78939}
-
- 28 Jan, 2022 1 commit
-
-
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}
-
- 27 Jan, 2022 1 commit
-
-
Nico Hartmann authored
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/+/3406750Reviewed-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}
-
- 20 Jan, 2022 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#78706}
-
- 18 Jan, 2022 1 commit
-
-
Nico Hartmann authored
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/+/3329792Reviewed-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}
-
- 09 Nov, 2021 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77799}
-
- 05 Nov, 2021 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77739}
-
- 30 Sep, 2021 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77168}
-
- 29 Sep, 2021 3 commits
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77152}
-
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: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77146}
-
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: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77145}
-
- 21 Jul, 2021 1 commit
-
-
Seth Brenith authored
Since most Torque-defined extern classes use @generateCppClass, it makes more sense to instead annotate the small number that don't. This is part of the cleanup work that Nico recommended in [1]. Classes that still have to opt out: - Those that can be converted by https://crrev.com/c/3015666 - HeapObject: sort of special since it's the root of the inheritance hierarchy. Generated code would include two declarations that don't compile until HeapObject is defined: bool IsHeapObject_NonInline(HeapObject o); explicit TorqueGeneratedHeapObject( Address ptr, HeapObject::AllowInlineSmiStorage allow_smi); - SmallOrdered*: these classes use templates on the C++ side, which is not currently representable in Torque. - SwissNameDictionary: according to a comment, the Torque generation for this class is incorrect. I haven't investigated further. Drive-by fix: make the Torque formatter keep LF on Windows rather than writing CRLF. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I1fbb5290f0c645842b84c53816c09bb3398206a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3028721Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75841}
-
- 10 May, 2021 1 commit
-
-
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: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob 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}
-
- 15 Mar, 2021 1 commit
-
-
Frank Emrich authored
This CL: a) Adds an unsigned 64 bit type to Torque, called uint64. b) Makes more operations on 64 bit integers from the raw machine assembler available in CSA and Torque. Change-Id: I147501d65882892e4628ec22088c0940df79a974 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742204 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#73403}
-
- 23 Feb, 2021 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72964}
-
- 09 Feb, 2021 1 commit
-
-
Nico Hartmann authored
This CL adds support for generating acquire/release accessors on class fields. Adds first use of this new feature (@acquireRead and @releaseWrite) on FunctionTemplateInfo::rare_data. Bug: v8:7790, v8:11122 Change-Id: I98f533807ab784d8667fd43564fe84686d27830c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679684Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72596}
-
- 03 Feb, 2021 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72499}
-
- 30 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
With this change, there are const and mutable version of slices, in analogy to const and mutable references, which we already have. A const slice as a readonly view into memory, it doesn't mean that nobody else has a writable view on it. An array field in a Torque class produces const slices if it is declared as const. Due to limitations in the Torque type system, mutable slices are not a subtype of const slices of the same type. Bug: v8:7793 Change-Id: I1ba96e1ee82bf03b5fdc824488981f2a6b5eae8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560195Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71481}
-
- 19 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
This uses the old trick from TypedArrays: a Smi-like all zero pattern plus an offset that actually contains a raw address to access off-heap data. Bug: v8:7793 Change-Id: Ia44448d4ff7e2dcaa02a2c5653f622fb93c3dd09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534817Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71287}
-
- 11 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
This CL lets Torque generate the Context C++ class and BodyDescriptor for Context. This requires two Torque changes: - Allow @generateBodyDescriptor on @abstract classes, since all Context classes share the same BodyDescriptor. - Add a new annotation @relaxedWrite, which makes C++ setters use WRITE_RELAXED_FIELD instead of WRITE_FIELD. Attention: As a side-effect, this CL disables using WRITE_RELAXED_FIELD by default for all non-array fields. If this causes problems, we should manually add @relaxedWrite to the corresponding fields. Bug: v8:7793 Change-Id: I735b310bcb36a3612d86c22efa9c0bfc108d4ca6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529453 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71123}
-
- 10 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 TBR=hpayer@chromium.org Change-Id: I88644c9476b74f57d3cf7a3056a9b70f1467b96d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489689 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71079}
-
- 09 Nov, 2020 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71048}
-
- 05 Nov, 2020 2 commits
-
-
Michael Achenbach authored
This reverts commit 26f10ecd. Reason for revert: GC stress failures: https://crbug.com/v8/11114 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} TBR=ulan@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org Change-Id: I4631db66a76f41cf62b400e8ee64df27e641a320 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793,v8:11114 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521911Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70994}
-
Tobias Tebbi authored
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/+/2489687Reviewed-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}
-
- 22 Oct, 2020 1 commit
-
-
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: Clemens Backes <clemensb@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70698}
-
- 27 Jul, 2020 1 commit
-
-
Tobias Tebbi authored
When mksnapshot fails on a static assert in Torque, print the statement and position from the Torque source. To enable special treatment, change the syntax of static asserts in Torque from StaticAssert() to static_assert() to align with assert() and check() statements. Bug: v8:7793 Change-Id: Idda8e3c342bdcefc893ff297f8d7727d2734c221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317314 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69069}
-
- 23 Jun, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68478}
-
- 30 May, 2020 1 commit
-
-
Tobias Tebbi authored
Bug: chromium:1086890 Change-Id: I8345f209d8f4e40a57df166664f403a6cf6c6652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222346 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#68085}
-
- 04 May, 2020 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67542}
-
- 29 Apr, 2020 1 commit
-
-
Igor Sheludko authored
... and bottlenecks for C++, CSA, Torque, TurboFan and hand-written assembly. Bug: v8:10391 Change-Id: I62f8c6f9c934b2cd492e550b7c25f1078c2c6a71 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134140 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67479}
-
- 18 Mar, 2020 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66759}
-
- 09 Mar, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66621}
-
- 26 Feb, 2020 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66465}
-
- 19 Feb, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66349}
-
- 07 Feb, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66182}
-
- 16 Jan, 2020 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I4fc039711eb9aa9d551144ea6fccc926d4803349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993290 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65808}
-
- 18 Dec, 2019 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65503}
-
- 10 Dec, 2019 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65397}
-
- 21 Nov, 2019 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65108}
-