- 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}
-
- 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}
-
- 21 May, 2020 1 commit
-
-
Seth Brenith authored
Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
-
- 28 Oct, 2019 1 commit
-
-
Seth Brenith authored
This change begins making use of the fact that Torque now knows about the relationship between classes and instance types, to replace a few repetitive lists: - Instance type checkers (single and range), defined in src/objects/instance-type.h - Verification dispatch in src/diagnostics/objects-debug.cc - Printer dispatch in src/diagnostics/objects-printer.cc - Postmortem object type detection in tools/debug_helper/get-object-properties.cc Torque is updated to generate four macro lists for the instance types, representing all of the classes separated in two dimensions: classes that correspond to a single instance type versus those that have a range, and classes that are fully defined in Torque (with fields and methods inside '{}') versus those that are only declared. The latter distinction is useful because fully-defined classes are guaranteed to correspond to real C++ classes, whereas only-declared classes are not. A few other changes were required to make the lists above work: - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does and avoid conflicts with the new macro-generated IsFiller method. This is the part I'm most worried about: I think the new name is an improvement for clarity and consistency, but I could imagine someone typing IsFiller out of habit and introducing a bug. If we'd prefer to keep the name IsFiller, my other idea is to rename FreeSpace to VariableSizeFiller and Filler to FixedSizeFiller. - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE. - Normalized the dispatched behavior for BigIntBase and HeapNumber. - Added a few new object printers. Bug: v8:7793 Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64597}
-
- 11 Oct, 2019 1 commit
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
-
- 24 May, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7793 Change-Id: Ic485dc953c80d055ff190b8be2a5434e5cdbeb5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624214 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61828}
-
- 14 May, 2019 1 commit
-
-
Sigurd Schneider authored
This CL introduces the new suffix '-tq' for Torque generated files, and replaces the infix 'FromDSL' in type names with a prefix 'TorqueGenerated'. Change-Id: I1e90460cc0c666da6cf5017e8b3cb7c39c6ac668 Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609798 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61490}
-
- 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}
-
- 18 Mar, 2019 1 commit
-
-
Z Duong Nguyen-Huu authored
Bug: v8:8952 Change-Id: I07b3491e644634f9712e89d1566718084a3686d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518812Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60307}
-
- 18 Jan, 2019 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: Ieb677e0989f77ed207567d468faec0bf92752967 Reviewed-on: https://chromium-review.googlesource.com/c/1388529Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58922}
-
- 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}
-
- 20 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Merging the temporary HeapObjectPtr back into HeapObject. Bug: v8:3770 Change-Id: I5bcd23ca2f5ba862cf5b52955dca143e531c637b Reviewed-on: https://chromium-review.googlesource.com/c/1386492 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58410}
-
- 18 Dec, 2018 2 commits
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: If88c285bf1528f03401d3a83349b61435ac79f85 Reviewed-on: https://chromium-review.googlesource.com/c/1382455 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#58337}
-
Jakob Kummerow authored
Bug: v8:5402 Change-Id: Ib2d7b24cdcf55e3dfa8d3b1665ac565904ac2112 Reviewed-on: https://chromium-review.googlesource.com/c/1379940Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58336}
-