- 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}
-
- 09 Jul, 2021 1 commit
-
-
Seth Brenith authored
I noticed a case where Torque can generate an invalid .inc file, and I think that it's worth adding a check that can emit an error during run_torque rather than letting the developer hit a C++ compilation failure later. Example error message, if you add @export to StrongDescriptorArray: Torque Error: Exported class StrongDescriptorArray cannot be in the same file as its parent extern class DescriptorArray Bug: v8:7793 Change-Id: Ia69124a4177bd7a53f95442249fae88cb16e354a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015655Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75662}
-
- 01 Jul, 2021 1 commit
-
-
Peter Kasting authored
There are still a few cases remaining that seem more controversial; I'll upload those separately. Bug: chromium:1066980 Change-Id: Iabbaf23f9bbe97781857c0c589f2b3db685dfdc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994804 Commit-Queue: Peter Kasting <pkasting@chromium.org> Auto-Submit: Peter Kasting <pkasting@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75494}
-
- 25 Jun, 2021 1 commit
-
-
Victor Gomes authored
Change-Id: I116a25fe586491f1a3aff6a486e69724d82115ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983207 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75381}
-
- 16 Jun, 2021 2 commits
-
-
Seth Brenith authored
Rather than letting a recursive macro expansion cause a stack overflow and crash the compiler, this change updates Torque to emit an error as soon as the recursion is detected. Eventually it would be nice to make Cast macros a little more magical so they don't require so much human effort to maintain, but at least this way Torque displays some information about what went wrong. An example error message (manually wrapped to 72 character width) follows. src/builtins/cast.tq:157:10: Torque Error: Recursive macro call to callable Cast<(class Context | Undefined | Zero)>(implicit class Context)(Object): (class Context | Undefined | Zero) src/builtins/cast.tq:758:3: Torque Error: Note: in specialization Cast<(class Context | Undefined | Zero)> requested here src/builtins/cast.tq:764:10: Torque Error: Note: in specialization Is<(class Context | Undefined | Zero), Object> requested here src/builtins/torque-internal.tq:64:3: Torque Error: Note: in specialization UnsafeCast<(class Context | Undefined | Zero)> requested here src/objects/contexts.tq:75:10: Torque Error: Note: in specialization ReferenceCast<(class Context | Undefined | Zero), Object> requested here src/builtins/iterator.tq:142:16: Torque Error: Note: in specialization ContextSlot<class Context, class Context, (class Context | Undefined | Zero)> requested here Bug: v8:11727 Change-Id: I7b5b1852dee16a6860f593f27783f6b2d9366146 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965032Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75184}
-
Igor Sheludko authored
... behind the v8_enable_external_code_space build flag. This is a first CL in a row of CLs that will make CodeDataContainer the only type of objects that could contain references to Code objects (besides the Code objects embedded into the generated code). Eventually these changes will allow us to move Code space out of the V8 heap cage. This CL adds |code| field to ensure that CodeDataContainer keeps the respective Code object alive and |code_entry_point| field that contains cached value of the code().InstructionStart(). Bug: v8:11880 Change-Id: Ie7ce75667d8da306797d203691b429671bc4530d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964093 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75179}
-
- 14 Jun, 2021 1 commit
-
-
Peter Kasting authored
TNode has a templated constructor from TNode<U>, but this doesn't take precedence over the auto-generated copy constructor, which results in a warning being fired. Fix by adding an explicit copy constructor that does what the templated constructor does, which in turn requires fixing some missing #includes that slipped by due to the lack of LazyTemplateChecks() in the autogenerated copy constructor. Bug: chromium:1213098 Change-Id: Iad40950261af8f88396be9227355e4e013837341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953503Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#75133}
-
- 07 Jun, 2021 1 commit
-
-
Camillo Bruni authored
- Add new Builtin enum - Move Builtins::Name:kXXX to Builtin::kXXX - Update existing code Follow CLs will unify the mix of using int builtin-ids and Builtins::Name to only use the new Builtin enum and changing it to an enum class. Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74995}
-
- 21 May, 2021 1 commit
-
-
Nico Hartmann authored
Generating C++ source files is very cumbersome using raw ostreams. This CL introduces a few classes und the torque::cpp namespace that build an abstraction of printing/formatting C++ source code (mostly functions for now). This is an initial implementation with a limited set of features and uses. Landing features incrementally shall avoid huge CLs (+reviews) and complex rebasing. Bug: v8:7793 Change-Id: I3ae869755156175c7b37ea9f649e2f9c431ce3a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784688Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#74705}
-
- 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}
-
- 07 May, 2021 1 commit
-
-
Nico Hartmann authored
This is the 1st CL in a series of CLs with the goal to significantly reduce the number of includes in torque-generated files to reduce the build time of Torque's output. So far, all torque-generated builtins included all (197) other builtins generated by Torque. This CL adds tracking of definition locations to Torque's ImplementationVisitor that enables it to only include those builtins that are actually needed for compilation. This change reduces the number of includes for the majority of builtins by 150-180 files. Bug: v8:11528 Change-Id: Id6f6dd60c9c0f197d14998e580f0fa5fbd60f194 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876859Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#74443}
-
- 16 Apr, 2021 3 commits
-
-
Leszek Swirski authored
This is a reland of ae0752df Reland fixes: * Remove UNREACHABLE() from constexpr switch, since we don't have a CONSTEXPR_UNREACHABLE() (it's ok, the switch is exhaustive for the enum anyway). * Fix IsRegisterArray trait to use public inheritance and size_t for std::array size. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} TBR=nicohartmann@chromium.org,clemensb@chromium.org,ishell@chromium.org,clemensb@chromium.org Bug: v8:11420 Change-Id: Icd1f6cdb3c178e74460044b1e9623139929ceba8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831872Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74010}
-
Leszek Swirski authored
This reverts commit ae0752df. Reason for revert: Predictably, constexpr issues on non-clang compilers. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} Bug: v8:11420 Change-Id: Ie5469c9253fc140590ac30b72db6eb1d93f86806 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831485 Auto-Submit: Leszek Swirski <leszeks@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/master@{#74000}
-
Leszek Swirski authored
Add a new CRTP StaticCallInterfaceDescriptor class, which provides static constexpr getters for a descriptor's registers, parameter counts, and so on. Each CallInterfaceDescriptor subclass is changed to extend StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself extending CallInterfaceDescriptor to still provide a dynamic lookup where needed. StaticCallInterfaceDescriptor provides a couple of customisation points, where it reads its CRTP derived descriptor's static fields and functions, with default fallbacks where appropriate. With these customisation points, the definition of CallInterfaceDescriptor subclasses is simplified to: a) Providing parameter names (as before) b) Providing parameter types (as before) c) Optionally setting flags (like kNoContext or kAllowVarArgs) as static booleans on the class. d) Optionally providing a `registers()` method that returns a std::array<Register, N> of registers that may be used for parameters (if not provided, this defaults to the implementation specific default register set). Parameter registers (and register count) are automagically set based on the number of parameters and number of given registers, with extra magic to ignore no_reg registers (to reduce ia32 special casing). The CallInterfaceDescriptorData is initialized based on these static functions, rather than manual per-descriptor initializers. This allows us to skip loading descriptors dynamically for CallBuiltin in Sparkplug, and instead lets us use a bit of template magic to statically set up arguments for the calls. Any other users of statically known descriptors will also benefit, thanks to C++ picking the static methods over the dynamic methods on the base class when available. Because we can remove various virtual functions and trigger heavier inlining of constantly known values, binary size slightly decreases with this change. Note that torque-generated descriptors are changed to use the same magic, rather than having Torque-specific magic, for consistency. Bug: v8:11420 Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73996}
-
- 15 Apr, 2021 1 commit
-
-
Dan Elphick authored
This should catch potential build file misconfigurations. Change-Id: I1bd1f808a4758e0d3b71c862cfc34e7b01e6fbd9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2827894 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73976}
-
- 12 Apr, 2021 1 commit
-
-
Wenyu Zhao authored
This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
-
- 06 Apr, 2021 1 commit
-
-
Shu-yu Guo authored
This is a reland of e28dadc2 The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
-
- 05 Apr, 2021 4 commits
-
-
Shu-yu Guo authored
This reverts commit 15c78b45. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview Original change's description: > Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" > > This is a reland of e28dadc2 > > Relanding to see if Win32 rel failures from > https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview > were infra flakes. Could not repro on try bots. > > Original change's description: > > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > > > Currently, IsolateRoot is both the address of the Isolate root and the > > base address of the pointer compression reservation. This CL teases the > > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > > > - In addition to V8_COMPRESS_POINTERS, add a > > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > > aliases to GetPtrComprCageBase. > > > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > No-Try: true > Bug: v8:11460 > Tbr: ishell@chromium.org > Tbr: rmcilroy@chromium.org > Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73792} Bug: v8:11460 Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545 Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73793}
-
Shu-yu Guo authored
This is a reland of e28dadc2 Relanding to see if Win32 rel failures from https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview were infra flakes. Could not repro on try bots. Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> No-Try: true Bug: v8:11460 Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73792}
-
Francis McCabe authored
This reverts commit e28dadc2. Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168 Auto-Submit: Francis McCabe <fgm@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/master@{#73791}
-
Shu-yu Guo authored
Currently, IsolateRoot is both the address of the Isolate root and the base address of the pointer compression reservation. This CL teases the two uses apart by renaming IsolateRoot to PtrComprCageBase. - In addition to V8_COMPRESS_POINTERS, add a V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). - Rename GetIsolate* helpers to GetPtrComprCageBase. When V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as aliases to GetPtrComprCageBase. - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. Bug: v8:11460 Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73790}
-
- 25 Mar, 2021 1 commit
-
-
Nico Hartmann authored
The implementation of Flatten() Torque generates for CSA struct types and the current implementation of EmitCCValue make heavy use of std::make_tuple and std::tuple_cat, which had a noticeable impact on build times of generated files including these outputs. This CL eliminates all uses of std::tuple_cat and most uses of std::make_tuple. Bug: v8:9861 Change-Id: Ib950b2c87983171b8c32c388fc115d2407087717 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784563 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73660}
-
- 23 Mar, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of ef808d3b Original change's description: > [torque] Protect against printing Type* pointers > > I've noticed a frequent mistake within Torque is to use Type* pointers > with ostream's operator<<, which causes it to print a hex pointer rather > than a descriptive string. This can cause confusing error messages for > users of the Torque compiler. This change is an idea to prevent future > incidences of that problem by adding a template overload that will cause > a compilation failure if anybody tries to use Type* in this way. It > found two incorrect uses of Type*, which I've corrected. > > Bug: v8:7793 > Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#73574} Bug: v8:7793 Change-Id: Id775c88d67c2fb4fbef38ef889c39dff3b6ff6b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778727Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73608}
-
- 22 Mar, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit ef808d3b. Reason for revert: Failures on TSAN: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/2981? Original change's description: > [torque] Protect against printing Type* pointers > > I've noticed a frequent mistake within Torque is to use Type* pointers > with ostream's operator<<, which causes it to print a hex pointer rather > than a descriptive string. This can cause confusing error messages for > users of the Torque compiler. This change is an idea to prevent future > incidences of that problem by adding a template overload that will cause > a compilation failure if anybody tries to use Type* in this way. It > found two incorrect uses of Type*, which I've corrected. > > Bug: v8:7793 > Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#73574} Bug: v8:7793 Change-Id: Ieee470aa3cd176b9e1ad21fe39b9939edcef5bd6 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778722 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#73576}
-
Seth Brenith authored
I've noticed a frequent mistake within Torque is to use Type* pointers with ostream's operator<<, which causes it to print a hex pointer rather than a descriptive string. This can cause confusing error messages for users of the Torque compiler. This change is an idea to prevent future incidences of that problem by adding a template overload that will cause a compilation failure if anybody tries to use Type* in this way. It found two incorrect uses of Type*, which I've corrected. Bug: v8:7793 Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73574}
-
- 15 Mar, 2021 2 commits
-
-
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}
-
Seth Brenith authored
Torque generally supports marking things as unused by adding a single underscore to the front of identifiers. For locals, this feature works fine. For macros, it's only half-implemented: attempting to look up a macro that starts with _ fails (as it should), but the compiler also complains if the macro is unused. This change avoids emitting the latter error. Bug: v8:7793 Change-Id: Ib021c053004a180dd31993d3ad06cde463bafd5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757208 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73397}
-
- 11 Mar, 2021 1 commit
-
-
Seth Brenith authored
While working on the Torque compiler, I've sometimes found it difficult to understand Torque's intermediate representation and how it corresponds to the output. In this change, I propose adding a build flag that instructs Torque to emit comments describing its IR, interspersed in the generated code. This is particularly useful for seeing the stack management instructions (Peek, Poke, and DeleteRange) which don't emit any corresponding C++ code. Bug: v8:7793 Change-Id: I24bdec47da76c9bd751b928d3cd92aa513dc6593 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748040Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73352}
-
- 09 Mar, 2021 2 commits
-
-
Seth Brenith authored
The generated Torque files class-verifiers.cc and class-debug-readers.cc currently include files which are part of v8_initializers, despite being used in unrelated build targets. This change removes the unnecessary inclusions. There is still a lot of code included via all-objects-inl.h, but that's because these files require full class definitions for every object type. Bug: v8:11528 Change-Id: Ib26496f2a30ef576f1101636e0aca2cafbfd1f37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2743087 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73301}
-
Dan Elphick authored
Removes unneeded dependency on src/builtins/torque-csa-header-includes.h from debug-macros.h and adds swiss-name-dictionary.h and ordered-hash-table.h to debug-macros.cc. Additionally adds a v8_libbase dep to torque_generated_definitions. As a result, gn check errors are reduced by 2. Bug: v8:7330 Change-Id: I0ff666eebd6814e4d52d776e455fd269db36b589 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2744040Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#73291}
-
- 08 Mar, 2021 1 commit
-
-
cjihrig authored
std::stod() on Solaris does not currently handle hex strings. This commit provides a workaround based on strtol() until proper stod() support is available. This was encountered while updating Node.js to V8 8.8. For more details see the following comment: https://github.com/nodejs/node/pull/36139#issuecomment-740131942 Change-Id: I16ed80a817f6d9105e7153b10824b1fee8520432 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692746Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#73255}
-
- 03 Mar, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Also add the qualifier `compiler::` to places where it should have been used in the first place. Bug: v9:6949 Change-Id: Ib5ca6829cd9d72b1e3047afc92363910c902bbbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731529Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#73155}
-
- 24 Feb, 2021 1 commit
-
-
Seth Brenith authored
Currently, some ScopeInfo fields are defined as indexed fields with a length of either one or zero, because the field might be present or it might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 , this strategy is not sustainable and we need a better way to represent optional fields so that we don't have to pass zero when accessing their only element. This change is a proposal to fix that problem. Syntax: I'm proposing using a question mark because TypeScript does, and Torque syntax looks somewhat like TypeScript. I don't feel strongly about this though, and I'm open to other suggestions. field_name?[condition_expression]: FieldType; Internal Torque compiler representation: Internally, I've updated the Torque compiler to still treat these fields as indexed, but with an extra flag saying they're optional. When getting a LocationReference for a field access expression on an optional field, Torque produces a Slice like it would for any other indexed field and subsequently calls AtIndex(0) to get a Reference. AtIndex can crash the process if the index is out of bounds (which is good), so some other parts of the Torque compiler need minor adjustments so that it doesn't take references to optional fields unless it actually needs them. Initialization: This proposal doesn't include any changes to initialization logic, so an optional field can still be initialized using '...' and an iterator. Perhaps we could introduce an Optional<T> struct for prettier initialization in a future change. Bug: v8:7793 Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306 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@{#73018}
-
- 23 Feb, 2021 2 commits
-
-
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}
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2601880 . Change-Id: I7ad9ca42201c49df7037e65671a50caabc1fdf98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2705256Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72961}
-
- 19 Feb, 2021 1 commit
-
-
Seth Brenith authored
This reverts commit f731e13f. Reason for revert: perf regressions, chromium:1179757 Original change's description: > Remove 'length' field from ScopeInfo > > ScopeInfo has a vestigial 'length' field from when it used to be a > FixedArray. This change removes that field, which saves some memory. > > More specifically: > > - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which > supplied the 'length' field. > - Privatize the FixedArray-style functions that provide access to > ScopeInfo fields by index, and move them from scope-info-inl.h to > scope-info.cc. Those functions are still used pretty heavily during > initialization (ScopeInfo::Create, etc.), but at least we can avoid > presenting them to the rest of the world. > - Change FactoryBase::NewScopeInfo to allocate the updated object shape. > It maintains the existing behavior of filling the newly-allocated > object with undefined, even though that's not a valid ScopeInfo and > further initialization is required. > - Move part of AccessorAssembler::ScriptContextTableLookup into a new > Torque macro, because it used to rely on casting ScopeInfo to > FixedArrayBase. > - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are > arrays. I think it makes more sense to list them under "(system)" in > the dev tools, like most other V8 internal types. > > Bug: v8:8952 > Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Mythri Alle <mythria@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72830} Bug: v8:8952 Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72855}
-
- 17 Feb, 2021 1 commit
-
-
Seth Brenith authored
ScopeInfo has a vestigial 'length' field from when it used to be a FixedArray. This change removes that field, which saves some memory. More specifically: - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which supplied the 'length' field. - Privatize the FixedArray-style functions that provide access to ScopeInfo fields by index, and move them from scope-info-inl.h to scope-info.cc. Those functions are still used pretty heavily during initialization (ScopeInfo::Create, etc.), but at least we can avoid presenting them to the rest of the world. - Change FactoryBase::NewScopeInfo to allocate the updated object shape. It maintains the existing behavior of filling the newly-allocated object with undefined, even though that's not a valid ScopeInfo and further initialization is required. - Move part of AccessorAssembler::ScriptContextTableLookup into a new Torque macro, because it used to rely on casting ScopeInfo to FixedArrayBase. - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are arrays. I think it makes more sense to list them under "(system)" in the dev tools, like most other V8 internal types. Bug: v8:8952 Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72830}
-
- 11 Feb, 2021 2 commits
-
-
Santiago Aboy Solanes authored
Reasons: * We disabled it more than a year ago for all configs * Not easy to re-enable * Not compatible with pointer compression as-is * Not compatible with concurrent TP/TF as-is * No concrete plans to re-enable it Also remove Map's layout_descriptor since it was only used for double field unboxing. Bug: v8:11422 Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72671}
-
Seth Brenith authored
Torque generates runtime accessor member functions for most class fields that are defined in .tq files, but fields with struct types are currently omitted. This change adds those accessors. As an example, if a .tq file defines the following: struct InternalClassStructElement { a: Smi; b: Smi; } class InternalClassWithStructElements extends HeapObject { const count: Smi; entries[count]: InternalClassStructElement; } Then the following accessors are generated to get and set each struct field within the 'entries' field: inline int entries_a(int i) const; inline void set_entries_a(int i, int value); inline int entries_b(int i) const; inline void set_entries_b(int i, int value); Bug: v8:7793 Change-Id: Ia40b5918e9d09f53ad8e78bc33f8629b8d6a79fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676926Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72662}
-
- 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}
-