- 10 Feb, 2021 1 commit
-
-
Seth Brenith authored
Previously in https://chromium-review.googlesource.com/c/v8/v8/+/2545573 I updated BasicBlockInstrumentor to use 64-bit floating-point values rather than 32-bit integers, so that it could never overflow. However, I've now learned that some builtins (particularly RecordWrite) are not allowed to use floating-point registers, and so running with basic block instrumentation enabled could produce incorrect results. This change switches back to 32-bit integers, but adds saturation logic. Bug: chromium:1170776 Change-Id: Icbd93919fb05f50d615ec479263142addbe15c9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685617Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72626}
-
- 19 Nov, 2020 1 commit
-
-
Seth Brenith authored
The basic block instrumentation currently uses 32-bit integers, which could overflow during a long profiling session. I considered upgrading them to 64-bit integers, but generating the correct instrumentation code for various architectures would be rather non-trivial. Instead, this change uses 64-bit floating-point values, which are simple and also have the nice behavior that they saturate rather than overflowing. Bug: v8:10470 Change-Id: I60f7456cb750091809803c03a85dd348dc614b58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545573Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71297}
-
- 22 Jul, 2020 1 commit
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
-
- 12 Jun, 2020 1 commit
-
-
Seth Brenith authored
The graph verifer caught this bug. The offset in a load instruction should be pointer-sized. Bug: v8:10605 Change-Id: I816165c9c9ef4f0d7fbdcaf9c70faf845dbbb9fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238016Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68324}
-
- 02 Jun, 2020 1 commit
-
-
Seth Brenith authored
This change adds more granular control to the behavior that was previously controlled by the single flag --turbo-profiling. With this change, it becomes possible to: - output information only about builtins, ignoring functions compiled at runtime - skip the very slow process of writing the schedule and disassembly for all builtins, if you only want the block counts and don't need verbose output This change also moves the output step from Shell::OnExit to Isolate::DumpAndResetStats so that it's more consistent with other features and works in hosts other than d8. Bug: v8:10470, v8:9119 Change-Id: I19b1caca3ff27a2e4a6fdc7ad2f8174f8d678b3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216717Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68104}
-
- 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}
-
- 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}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 19 Dec, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: I0dab49a03b74abc68600885f4951c5cb727a3d73 Reviewed-on: https://chromium-review.googlesource.com/c/1366736Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58364}
-
- 14 Aug, 2018 1 commit
-
-
Stephan Herhut authored
Data object for tick collection are now created in a thread save way and the block ids for counters use the same numbers as the printed schedule. Change-Id: I7a35088cb2fcd94a81067b16ad12b01d380fefa5 Reviewed-on: https://chromium-review.googlesource.com/1152923 Commit-Queue: Stephan Herhut <herhut@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55124}
-
- 26 Jul, 2018 1 commit
-
-
Stephan Herhut authored
This is a first step to make basic block profiling work in wasm. More is needed, including eventually making the profiler thread safe. Change-Id: Ic216c881a4ab5a633e147e5538bb405c32e687cd Reviewed-on: https://chromium-review.googlesource.com/1150234 Commit-Queue: Stephan Herhut <herhut@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54728}
-
- 04 Apr, 2018 1 commit
-
-
Ross McIlroy authored
With the Ignition + Turbofan pipeline there is very little overlap between the data needed for unoptimized compilation and optimized compilation. As a result, it is cleaner to split up the CompilationInfo into UnoptimizedCompilationInfo and OptimizedCompilationInfo. Doing so also necessitate splitting up CompilationJob into UnoptimizedCompilationJob and OptimizedCompilationJob - again there is not much overlap so this seems cleaner. Change-Id: I1056ad520937b7f8582e4fc3ca8f4910742de30a Reviewed-on: https://chromium-review.googlesource.com/995895 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52369}
-
- 16 Mar, 2018 1 commit
-
-
Camillo Bruni authored
With this CL the name of an SFI is either stored directly on the SFI itself (for uncompiled ones) or on the related ScopeInfo if present. - Combine scope_info and name field on SFI into name_or_scope_info field - Change the name of a couple of SFI accessors: name => Name, has_shared_name => HasSharedName, set_name => SetName - Add Runtime::kGetFunctionName due to more complex SFI name accessing Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Idcce158446c9447b92d9a15125d086952c6e0824 Reviewed-on: https://chromium-review.googlesource.com/964201 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52001}
-
- 15 Nov, 2017 1 commit
-
-
Ross McIlroy authored
Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
-
- 06 Jun, 2017 1 commit
-
-
Igor Sheludko authored
Properly propagate the fact that the function has a statically known name from parser to SharedFunctionInfo objects. The empty string that has been set as name before this CL does not help to distinguish cases like: var o1 = { ''(){} }; var o1 = { [foo()](){} }; or var o2 = { get ''(){} }; var o2 = { get [foo()](){} }; This is a preliminary step for using different layouts for closure objects with and without computed names. TBR=bmeurer@chromium.org, marja@chromium.org Bug: v8:6459 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d Reviewed-on: https://chromium-review.googlesource.com/522073 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45744}
-
- 31 Aug, 2016 1 commit
-
-
marja authored
This way, many files which only need CompilationInfo but not compiler.h and its dependencies can include just compilation-info.h. BUG= Review-Url: https://codereview.chromium.org/2284313003 Cr-Commit-Position: refs/heads/master@{#39038}
-
- 26 Aug, 2016 1 commit
-
-
mstarzinger authored
R=marja@chromium.org Review-Url: https://codereview.chromium.org/2281543002 Cr-Commit-Position: refs/heads/master@{#38926}
-
- 11 Dec, 2015 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1513383003 Cr-Commit-Position: refs/heads/master@{#32803}
-
- 10 Dec, 2015 1 commit
-
-
jarin authored
MachineType is now a class with two enum fields: - MachineRepresentation - MachineSemantic Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably: - register allocator now uses just the representation. - Phi and Select nodes only refer to representations. Review URL: https://codereview.chromium.org/1513543003 Cr-Commit-Position: refs/heads/master@{#32738}
-
- 23 Sep, 2015 3 commits
-
-
jarin authored
(Original CL: https://codereview.chromium.org/1347353003/) Unfortunately, the mips gcc gets confused by arraysize on variadic templated arguments, so we use sizeof... instead. Review URL: https://codereview.chromium.org/1366543003 Cr-Commit-Position: refs/heads/master@{#30880}
-
machenbach authored
Revert of [turbofan] Checking of input counts on node creation (patchset #4 id:60001 of https://codereview.chromium.org/1347353003/ ) Reason for revert: [Sheriff] Breaks mips cross-compile: http://build.chromium.org/p/client.v8/builders/V8%20Mips%20-%20builder/builds/4315 Original issue's description: > [turbofan] Checking of input counts on node creation > > This required fixing bunch of tests with wrong input counts. > > Committed: https://crrev.com/260ec46efd74c45cdc4b156d95086b7de06621ad > Cr-Commit-Position: refs/heads/master@{#30877} TBR=bmeurer@chromium.org,mstarzinger@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1362783004 Cr-Commit-Position: refs/heads/master@{#30878}
-
jarin authored
This required fixing bunch of tests with wrong input counts. Review URL: https://codereview.chromium.org/1347353003 Cr-Commit-Position: refs/heads/master@{#30877}
-
- 09 Mar, 2015 1 commit
-
-
titzer authored
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code). BUG= Review URL: https://codereview.chromium.org/974213002 Cr-Commit-Position: refs/heads/master@{#27078}
-
- 22 Jan, 2015 1 commit
-
-
bmeurer authored
- Move unit tests to schedule-unittests.cc. - Remove pre-C++11 cruft. - Fix some include weirdness. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/864293002 Cr-Commit-Position: refs/heads/master@{#26220}
-
- 23 Dec, 2014 1 commit
-
-
bmeurer authored
TEST=cctest,unittests R=jochen@chromium.org Review URL: https://codereview.chromium.org/821913002 Cr-Commit-Position: refs/heads/master@{#25935}
-
- 10 Nov, 2014 1 commit
-
-
titzer@chromium.org authored
Lowering of NumberToUint32 and NumberToInt32 was not correctly accounting for the sign of the input and the sign of the output, emitting the wrong representation changes. Along the way, I've found cases where MachineOperatorBuilder would break if fed a machine type for loads or stores that was not cached, requiring MachineOperatorBuilder to take zone to allocate operators for these cases. R=bmeurer@chromium.org, jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/714613002 Cr-Commit-Position: refs/heads/master@{#25247} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Sep, 2014 2 commits
-
-
bmeurer@chromium.org authored
Review URL: https://codereview.chromium.org/618643002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24319 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jarin@chromium.org authored
To manage BasicBlock's predecessors and successors we now use plain std::vector. The change also moves bunch of method definitions from header files to implementation files. In zlib, the change brings 3x improvement in the scheduler's memory consumption. The --turbo-stats flag says we go 169MB -> 55MB in the scheduler, 383MB -> 268MB overall. BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/606403003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24308 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Sep, 2014 1 commit
-
-
dcarney@chromium.org authored
R=titzer@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/593563005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24263 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-