- 17 May, 2021 1 commit
-
-
Philip Pfaffe authored
This is a reland of 0ce36e7d The reland includes two fixes: - Move the EvaluateGlobalForTesting into libv8 to avoid linkage issues and to avoid having to export ThreadLocalTop symbols. - Give the ExecutionMode enum a uint8_t backing type to avoid endianess issues. Original change's description: > [ic] Fix handling of API properties with side effects > > DebugEvaluate can evaluate expressions in side-effect-free mode, where > any operation that would cause observable side effects throws an > exception. Currently, when accessors are backed by callbacks, it's > possible that ICs call those accessors directly, bypassing the > side-effect checks. This CL introduces a bailouts to runtime in those > cases. > > Fixed: chromium:1201781 > Also-By: ishell@chromium.org, pfaffe@chromium.org > Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634 > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74507} Fixes: v8:11761 Change-Id: I58cde8bd11ba0fc9d83adc19fa87733628ab6c13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891829Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Cr-Commit-Position: refs/heads/master@{#74602}
-
- 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}
-
- 11 Feb, 2021 1 commit
-
-
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}
-
- 08 Jan, 2021 1 commit
-
-
Benedikt Meurer authored
Previously we had introduced a special `v8::internal::WasmValue` type which we used to expose Wasm values to the Scope view in Chromium DevTools. The problem however is that these values cannot be exposed to JavaScript (and in particular not to Debug Evaluate), which means that particularly for v128 and i64 we have inconsistent representations across the various parts of DevTools. This change removes the `wasm` type from the RemoteObject and all the adjacent logic, and paves the way for a uniform representation of Wasm values throughout DevTools. For i64 we will simply use BigInt consistently everywhere, and for i32, f32 and f64 we'll just use Number. For externref we will represent the values as-is directly. For v128 values we currently use a Uint8Array, but will introduce a dedicated WasmSimd128 class in a follow-up CL. Bug: chromium:1071432 Fixed: chromium:1159402 Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428Reviewed-by: Zhi An Ng <zhin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#71962}
-
- 30 Nov, 2020 1 commit
-
-
Nico Hartmann authored
This is the 3rd step in a series of CLs to move the SharedFunctionInfo class to kNeverSerialized and make it concurrently accessible from the background thread. This CL: * Adds synchronization to PrepareFunctionForDebugExecution * Adds tests that mess with SharedFunctionInfo while it is accessed by another thread. Bug: v8:7790 Change-Id: I2200fc7b6e977cda4e1003cb83d6ff49b1f1e337 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523318Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71495}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 25 Sep, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 22 Sep, 2020 2 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
- 27 May, 2020 1 commit
-
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . It allows scoped lookups to not crash during CompileCurrentAst, fixes the formatting in an error message, and includes an extra line for convenience when generating macros for bitfields. Change-Id: I7ed9f7d76b3ce5e2cc0f2580d7ba1953da340ae8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216301Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68018}
-
- 26 May, 2020 1 commit
-
-
Seth Brenith authored
This reverts commit 4e5fabae. Reason for revert: performance regressions chromium:1085305, chromium:1084978 Original change's description: > [torque][cleanup] Use more precise field types in a few classes > > This change updates some Torque-defined classes to include more precise > field types where possible. It also updates those classes to use > @generateCppClass. One field was removed because it's unused > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo > actually became less precise because they're based on Script::name, > which is an embedder-provided untyped Local<Value>. (Automatically > generated accessors pointed out this bug easily.) > > This change also includes a couple of minor fixes in Torque. > > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67907} TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67972}
-
- 19 May, 2020 1 commit
-
-
Seth Brenith authored
This change updates some Torque-defined classes to include more precise field types where possible. It also updates those classes to use @generateCppClass. One field was removed because it's unused (PrototypeInfo::validity_cell), and two fields in StackFrameInfo actually became less precise because they're based on Script::name, which is an embedder-provided untyped Local<Value>. (Automatically generated accessors pointed out this bug easily.) This change also includes a couple of minor fixes in Torque. Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67907}
-
- 11 May, 2020 1 commit
-
-
Seth Brenith authored
This CL is pretty mechanical; I just iterated through some Torque classes making the following changes: - Use @generateCppClass if it seems easy to - Use @generatePrint if the existing printer doesn't do anything special - Fix up any imprecise field types It also includes two minor changes to implementation-visitor: - Add a new -inl.h file with the things needed for torque-generated/class-definitions-tq.cc so we don't need to keep changing the compiler when we add @generateCppClass. - Avoid emitting incorrect accessors for ExternalPointers. This isn't strictly necessary for correctness, as the accessors defined in C++ already hide the ones inherited from generated code, but it makes me feel safer. Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#67719}
-
- 15 Apr, 2020 1 commit
-
-
Ng Zhi An authored
This debug::WasmValue is a wrapper around internal::WasmValue. It is exposed to the inspector, and contains helper methods to get the type and underlying bytes of the Wasm value. This will later be used by the inspector, in value-mirror, to expose the WasmValue to DevTools via CDP. Bug: v8:10347 Change-Id: I1ee20c0be3a20dad2cfe3994a166e9a284af5d4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137864Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67160}
-
- 06 Apr, 2020 1 commit
-
-
Ng Zhi An authored
WasmValue holds a Wasm value with its type. This will be exposed to the inspector (via a to-be-created class in debug_interface.h) for debugging in DevTools. Design at http://doc/1XQlX6DWsv6BPYnRtw-JZSASPEjsRlyXLnke7TTQ9Wrg. Bug: v8:10347 Change-Id: Ib523e617d46fdf1adb13d13bf49749c4ce23a126 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132720Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67029}
-
- 18 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the runtime, we always had a convention to use int-typed accessors for Smi fields. For Torque-generated classes, we kept them Smi-typed but then added int wrappers around that. This CL makes Torque generate int-typed accessors directly, removing the need for these wrappers. TBR=hpayer@chromium.org Bug: v8:7793 Change-Id: I348e1d96295c9676fafda32b7d49088848527f89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66760}
-
- 26 Feb, 2020 2 commits
-
-
Seth Brenith authored
This allows Torque code to refer to these bitfields (not currently relevant for any of these classes), and allows the postmortem debugging API to provide details about these bitfields. Change-Id: I79c74a3c5ef1f77e839720a4e8ee1f8482a576ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049870 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66471}
-
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}
-
- 18 Feb, 2020 1 commit
-
-
Seth Brenith authored
This allows CoverageInfo to be distinguished from other kinds of FixedArray at runtime. I also updated it to use untagged data since it only stores ints, since that seems like the generally right thing to do (even though I doubt anybody allocates enough of these to notice the reduced GC work). Related Torque changes: - Allow structs containing untagged data to be used as class fields. This requires classifying them into the tagged or untagged sections of the class layout, and checking that their alignment requirements are met when stored in a packed array. - Generate a struct containing struct field offsets, so we can ensure that the layouts defined in Torque and C++ code match. Of course it would be nice to generate a lot more (indexed accessors, synchronized accessors, GC visitors, etc.), but we can't do it all at once. Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66318}
-
- 12 Feb, 2020 1 commit
-
-
Seth Brenith authored
The list of forward declarations required in the generated file bit-fields-tq.h is already somewhat unwieldy and will run into serious problems when we attempt to use enums that are defined within classes, such as JSDateTimeFormat::DateTimeStyle. After a brief discussion today, the cleanest solution we arrived at is to generate macros instead. Change-Id: I654e10efbab5a1a0a340fa565c51ff1da34badaa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050830Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66240}
-
- 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}
-
- 09 Jan, 2020 1 commit
-
-
Seth Brenith authored
This change updates CachedTemplateObjectMap, BreakPointInfo, and BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3. It also removes Tuple3 because nothing else used Tuple3. By avoiding tuple types, we get various benefits that Torque can provide: - stricter debug verifier functions - accessors, cast functions, and printers are generated - BreakPoint and BreakPointInfo have different instance types, so you can tell them apart at runtime or in a debugger Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65668}
-
- 18 Dec, 2019 1 commit
-
-
Z Nguyen-Huu authored
In setting breakpoint in wasm, we can find wasm script from location but in removing a breakpoint, only breakpoint id is provided. For wasm, we have a list of all BreakPointInfo objects attached to the Script. From breakpoint id, we iterates all scripts to find the targeted breakpoint and remove it. Bug: chromium:837572 Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65505}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 07 Oct, 2019 1 commit
-
-
Seth Brenith authored
Just mechanical conversion to remove boilerplate code. When .tq and .h files didn't agree on what a field is named, I used the name from the .h file. In a couple of cases the generated accessor became slightly more specific (HeapObject instead of Object), and I had to update the code that uses those accessors accordingly. Change-Id: Ie3af1590e3889887b167c9d045b07860b01f7d15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776479Reviewed-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@{#64142}
-
- 13 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 24 Apr, 2019 1 commit
-
-
Jakob Gruber authored
When collecting JS block coverage, we track block execution counts on so-called CoverageInfo objects. Generated bytecode and native code contains inlined snippets of code to increment the appropriate counters. These used to be implemented as calls to the IncBlockCounter runtime function. Each call incurred the entire CEntry overhead. This CL reduces that overhead by moving logic over into a new IncBlockCounter TFS builtin. The builtin is called directly from bytecode, and lowered to the same builtin call for optimized code. Drive-by: Tweak CoverageInfo layout to generate faster code. Tbr: jarin@chromium.org Bug: v8:9149, v8:6000 Change-Id: I2d7cb0db649edf7c56b5ef5a4683d27b1c34605c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571420Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60981}
-
- 29 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in src/objects to 'using' declarations. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: Iec455b40e9256ee3aae867a42c0e949a338d417c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545893Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60531}
-
- 13 Feb, 2019 1 commit
-
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
- 09 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The incremental migration required several pairs of functionally equivalent macros. This patch consolidates everything onto the respective new version and drops the obsolete versions. Bug: v8:3770 Change-Id: I4fb05ff223e8250c83a13f46840810b0893f410b Reviewed-on: https://chromium-review.googlesource.com/c/1398223Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58659}
-
- 26 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tbr: ahaas@chromium.org,leszeks@chromium.org,verwaest@chromium.org Bug: v8:3770 Change-Id: Ia6530fbb70dac05e9972283781c3550d8b50e1eb Reviewed-on: https://chromium-review.googlesource.com/c/1390116 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58470}
-
- 18 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Dropping the temporary StructPtr in the process. Bug: v8:3770 Change-Id: I70784ede7b66b432d8438536ff0c70a51dfb7f83 Reviewed-on: https://chromium-review.googlesource.com/c/1377461 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#58315}
-
- 17 Dec, 2018 2 commits
-
-
Jakob Kummerow authored
Tuple2 and subclasses: EnumCache, SourcePositionTableWithFrameCache, TemplateObjectDescription Bug: v8:3770 Change-Id: Icff0860a04445dda542119834ef9866167ba2263 Reviewed-on: https://chromium-review.googlesource.com/c/1377772 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58287}
-
Jakob Kummerow authored
BreakPoint, BreakPointInfo, DebugInfo Bug: v8:3770 Change-Id: Ibad956b0933b5e994407475faaf4a8770e455318 Reviewed-on: https://chromium-review.googlesource.com/c/1377458 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58269}
-
- 14 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
along with subclasses: Tuple2, Tuple3, FeedbackCell, AccessorPair. The latter two can be separated out later if desired. Bug: v8:5402 Change-Id: I4e1a6d2621cc6f96b5da208cff0da7cd5de91672 Reviewed-on: https://chromium-review.googlesource.com/c/1371038Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58251}
-
- 28 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: If405611d359d29ae1958beebd9202e068434a621 Reviewed-on: https://chromium-review.googlesource.com/c/1350286 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57918}
-
- 27 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I4da6404aa968adca1fbb49029fc304622101d6c3 Reviewed-on: https://chromium-review.googlesource.com/c/1349112 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57853}
-
- 25 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Removing the temporarily duplicated classes FixedArrayPtr and FixedArrayBasePtr. Bug: v8:3770 Change-Id: I056ad74ff69593e9f134ef5c976766812c4d9275 Reviewed-on: https://chromium-review.googlesource.com/c/1345913 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#57807}
-